From owner-ietf-smime@mail.imc.org Fri May 2 11:05:18 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 387D73A6C10 for ; Fri, 2 May 2008 11:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.550, 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 7vmbjwLeR0ML for ; Fri, 2 May 2008 11:05:17 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 0D39F3A6E13 for ; Fri, 2 May 2008 11:04: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 m42Hh0kQ078607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 10:43:00 -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 m42Hh0oD078606; Fri, 2 May 2008 10:43:00 -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 smtp105.biz.mail.re2.yahoo.com (smtp105.biz.mail.re2.yahoo.com [206.190.52.174]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m42HgxJA078597 for ; Fri, 2 May 2008 10:43:00 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 97220 invoked from network); 2 May 2008 17:42:53 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@71.191.1.177 with login) by smtp105.biz.mail.re2.yahoo.com with SMTP; 2 May 2008 17:42:53 -0000 X-YMail-OSG: KCw.VrkVM1kFU_LJO7TZfMeOeFlVXU73Zj1QggsD7CfnuVQ2XE75iGoCBLLGf9fQo4fP2PLFpysGp.AjOj6WUptmT1mkINcIYysOZuMQtMgEvknVGRWrM.OdRubC0nUHaBU- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: References: <019501c889f4$8185e340$0301a8c0@Wylie> <200803192107.m2JL7PYY060318@balder-227.proper.com> <00b401c88e82$d983df10$0301a8c0@Wylie> Subject: RE: S/MIME v3.2 IDs key size text Date: Fri, 2 May 2008 13:39:03 -0400 Organization: IECA, Inc. Message-ID: <008501c8ac7b$6a1e88c0$0201a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciOo6ubmDvRbsL0T2OcCb8+6E2KgQd1rSog X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul has suggest a rewording of his text for 4.1 as follows: A receiving agent needs to be able to verify signatures whose key length is chosen by the signer. For interoperability, a receiving agent MUST be able to verify signatures whose key length is 1024 bits or shorter. Being able to verify signatures is mandatory because earlier versions of this specification required the ability to generate signatures with shorter key lengths. Note that most receiving agents are likely to see signatures whose key length is longer than 1024 bits during the next decade, and those receiving agents will want to be able to verify those signatures. He's also suggested the following security consideration: Receiving agents are only required to validate signatures that are the same length as sending agents are required to produce, namely 1024 bits. Many people feel that signatures of 1024 bits do not meet their security requirements today, or even if they meet their requirements today, they will not meet their requirements in the foreseeable future. Therefore, sending and receiving agents need to decide what strength of signature they want to produce and validate, respectively. Further, those decisions need to be reviewed periodically in light of decreasing cryptographic strength over time of signatures. spt >-----Original Message----- >From: Paul Hoffman [mailto:phoffman@imc.org] >Sent: Tuesday, March 25, 2008 2:12 PM >To: Turner, Sean P.; 'Russ Housley'; ietf-smime@imc.org >Subject: RE: S/MIME v3.2 IDs key size text > >At 10:16 AM -0400 3/25/08, Turner, Sean P. wrote: >>This sounds reasonable. I replace the following sentence in 3851bis: >> >>A receiving agent SHOULD be able to verify signatures with >keys of any >>size over 512 bits. >> >>with >> >>A receiving agent SHOULD be able to verify signatures with keys up to >>16384 bits. > >I disagree with the upper limit. Verifying signatures with 16K >bit keys is very difficult for constrained devices; this >"SHOULD" may have the effect of making device makers need to >use faster CPUs than they would normally want to have. > >It is unclear which part of the SHOULD is not a MUST here. >Because we are talking only about interoperability, then the >number is 1024, which is what the key creators SHOULD be >making. But that is clearly a lower bound of what a typical >receiver might expect. Therefore, a short sentence like the >one proposed is insufficient. How about: > >A receiving agent needs to be able to verify signatures whose >key length is chosen by the signer. At a minimum, a receiving >agent MUST be able to verify signatures whose key length is >1024 bits or shorter. However, most receiving agents are >likely to see signatures whose key length is longer than that >during the next decade. From owner-ietf-smime@mail.imc.org Fri May 2 11:12: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 E90FF3A6ABD for ; Fri, 2 May 2008 11:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 3dH1EwYv6pBP for ; Fri, 2 May 2008 11:12:04 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C6CEC3A6826 for ; Fri, 2 May 2008 11:12:03 -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 m42HjXct079652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 10:45: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 m42HjXYh079651; Fri, 2 May 2008 10:45: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 mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m42HjWxQ079635 for ; Fri, 2 May 2008 10:45:33 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 8A49628C362; Fri, 2 May 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-rfc3278-update-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080502174502.8A49628C362@core3.amsl.com> Date: Fri, 2 May 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 : Update to Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) Author(s) : S. Turner Filename : draft-ietf-smime-rfc3278-update-03.txt Pages : 28 Date : 2008-5-2 RFC 3278 describes how to use Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic Message Syntax (CMS). This document updates RFC 3278 to add support for the SHA2 family of hash algorithms, Elliptic Curve Digital Signature Algorithm (ECDSA) 224-512, and Key Derivation Functions (KDFs) that utilize SHA2 algorithms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc3278-update-03.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-rfc3278-update-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-5-2104433.I-D@ietf.org> --NextPart-- From owner-ietf-smime@mail.imc.org Fri May 2 11:33: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 67F993A6826 for ; Fri, 2 May 2008 11:33:58 -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 q66cNrhzWt+x for ; Fri, 2 May 2008 11:33:57 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 866C728C225 for ; Fri, 2 May 2008 11:33:45 -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 m42IGSJs093793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 11:16:28 -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 m42IGSmb093791; Fri, 2 May 2008 11:16:28 -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 mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m42IGQ98093775 for ; Fri, 2 May 2008 11:16:27 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 1665418827; Sat, 3 May 2008 06:16:26 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHWyRL8SxogE; Sat, 3 May 2008 06:16:25 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 5CCDC18823; Sat, 3 May 2008 06:16:24 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id EEEBC19EC0B9; Sat, 3 May 2008 06:16:23 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1Jrznz-0005zT-Rs; Sat, 03 May 2008 06:16:23 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org, turners@ieca.com Subject: RE: S/MIME v3.2 IDs key size text In-Reply-To: <008501c8ac7b$6a1e88c0$0201a8c0@Wylie> Message-Id: Date: Sat, 03 May 2008 06:16:23 +1200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Turner, Sean P." writes: >A receiving agent needs to be able to verify signatures whose key length is >chosen by the signer. For interoperability, a receiving agent MUST be able to >verify signatures whose key length is 1024 bits or shorter. [...] >Receiving agents are only required to validate signatures that are the same >length as sending agents are required to produce, namely 1024 bits. Aren't these mutually exclusive? (The "or shorter" attached to the "1024" is also going to prove problematic with FIPS-evaluated crypto implementations, since you can't do < 1024 bits for those). Peter. From owner-ietf-smime@mail.imc.org Fri May 2 11:55:36 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 8360D3A6CF1 for ; Fri, 2 May 2008 11:55:36 -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 JuXmrHDL8aWd for ; Fri, 2 May 2008 11:55:35 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C14153A6E27 for ; Fri, 2 May 2008 11:53:58 -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 m42Ia00X002138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 11:36:00 -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 m42Ia00d002136; Fri, 2 May 2008 11:36:00 -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 m42IZvr2002115 for ; Fri, 2 May 2008 11:36:00 -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 1Js06v-0002h6-1S; Fri, 02 May 2008 14:35:57 -0400 From: "Tony Capel" To: "'Turner, Sean P.'" , Subject: RE: S/MIME v3.2 IDs key size text Date: Fri, 2 May 2008 14:35:55 -0400 Message-ID: <002701c8ac83$5bc1cd20$02b5a8c0@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 Thread-Index: AciOo6ubmDvRbsL0T2OcCb8+6E2KgQd1rSogAAFe1rA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <008501c8ac7b$6a1e88c0$0201a8c0@Wylie> Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sean: I think the minimum supported size needs to be 2048 because: 1) Since at least April 2007 (over a year ago) Verisign has been issuing = certs with 2048 keys (I believe this is selectable when enrolling) (although = the root cert is only 1024!). 2) NIST is recommending 2048 by end of 2008 for signatures and key = transport for some apps [SP-800-78-1 Table 3.1]. 3) Many/most hardware tokens (e.g. Safenet, Gem, Aladdin) are supporting = 1024 and 2048 (only). As far as going larger than 2048, in my brief survey, while there = appears to be a small level of interest in 3072 (and even 4096), beyond that many = appear to be recommending a switch to ECC because of the exponentially rising = power/cpu costs for larger RSA sizes (e.g. NSA Suite B). So I would suggest making 2048 and smaller mandatory. And using a = sentence like: " Note that receiving agents may see signatures whose key length is = longer than 2048=20 bits in the future, and support for lengths of 3072 and 4078 SHOULD be = provided to verify those signatures." Or "... for lengths up to and including 4078 SHOULD ..." to address optional support. 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: May 2, 2008 1:39 PM | To: ietf-smime@imc.org | Subject: RE: S/MIME v3.2 IDs key size text |=20 |=20 |=20 | Paul has suggest a rewording of his text for 4.1 as follows: |=20 | A receiving agent needs to be able to verify signatures whose=20 | key length is chosen by the signer. For interoperability, a=20 | receiving agent MUST be able to verify signatures whose key=20 | length is 1024 bits or shorter. Being able to verify=20 | signatures is mandatory because earlier versions of this=20 | specification required the ability to generate signatures=20 | with shorter key lengths. Note that most receiving agents are=20 | likely to see signatures whose key length is longer than 1024=20 | bits during the next decade, and those receiving agents will=20 | want to be able to verify those signatures. |=20 | He's also suggested the following security consideration: |=20 | Receiving agents are only required to validate signatures=20 | that are the same length as sending agents are required to=20 | produce, namely 1024 bits. Many people feel that signatures=20 | of 1024 bits do not meet their security requirements today,=20 | or even if they meet their requirements today, they will not=20 | meet their requirements in the foreseeable future. Therefore,=20 | sending and receiving agents need to decide what strength of=20 | signature they want to produce and validate, respectively.=20 | Further, those decisions need to be reviewed periodically in=20 | light of decreasing cryptographic strength over time of signatures. |=20 | spt |=20 | >-----Original Message----- | >From: Paul Hoffman [mailto:phoffman@imc.org] | >Sent: Tuesday, March 25, 2008 2:12 PM | >To: Turner, Sean P.; 'Russ Housley'; ietf-smime@imc.org | >Subject: RE: S/MIME v3.2 IDs key size text | > | >At 10:16 AM -0400 3/25/08, Turner, Sean P. wrote: | >>This sounds reasonable. I replace the following sentence in 3851bis: | >> | >>A receiving agent SHOULD be able to verify signatures with | >keys of any | >>size over 512 bits. | >> | >>with | >> | >>A receiving agent SHOULD be able to verify signatures with=20 | keys up to | >>16384 bits. | > | >I disagree with the upper limit. Verifying signatures with 16K | >bit keys is very difficult for constrained devices; this=20 | >"SHOULD" may have the effect of making device makers need to=20 | >use faster CPUs than they would normally want to have. | > | >It is unclear which part of the SHOULD is not a MUST here. | >Because we are talking only about interoperability, then the=20 | >number is 1024, which is what the key creators SHOULD be=20 | >making. But that is clearly a lower bound of what a typical=20 | >receiver might expect. Therefore, a short sentence like the=20 | >one proposed is insufficient. How about: | > | >A receiving agent needs to be able to verify signatures whose | >key length is chosen by the signer. At a minimum, a receiving=20 | >agent MUST be able to verify signatures whose key length is=20 | >1024 bits or shorter. However, most receiving agents are=20 | >likely to see signatures whose key length is longer than that=20 | >during the next decade. |=20 From owner-ietf-smime@mail.imc.org Fri May 2 14:55: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 24AD93A69A2 for ; Fri, 2 May 2008 14:55:48 -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 C8uuMHXoWMuz for ; Fri, 2 May 2008 14:55:47 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id E4E793A69AA for ; Fri, 2 May 2008 14:55:46 -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 m42LhtVa086134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 14:43:55 -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 m42Lht6u086131; Fri, 2 May 2008 14:43:55 -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 m42Lhorp086080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 2 May 2008 14:43:54 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <002701c8ac83$5bc1cd20$02b5a8c0@tony> References: <002701c8ac83$5bc1cd20$02b5a8c0@tony> Date: Fri, 2 May 2008 14:43:30 -0700 To: From: Paul Hoffman Subject: RE: S/MIME v3.2 IDs key size text 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:35 PM -0400 5/2/08, Tony Capel wrote: >I think the minimum supported size needs to be 2048 because: Please be more specific. Supported for what? Signing, verifying, or both? >1) Since at least April 2007 (over a year ago) Verisign has been issuing certs >with 2048 keys (I believe this is selectable when enrolling) >(although the root >cert is only 1024!). >2) NIST is recommending 2048 by end of 2008 for signatures and key >transport for >some apps [SP-800-78-1 Table 3.1]. >3) Many/most hardware tokens (e.g. Safenet, Gem, Aladdin) are supporting 1024 >and 2048 (only). The wording clearly says that you should expect to validate larger keys, which are covered by those three data points. Your last point (hardware tokens signing at 1024) is exactly why I think mandating the ability to sign at least 1024 bits is a good idea. >As far as going larger than 2048, in my brief survey, while there >appears to be >a small level of interest in 3072 (and even 4096), beyond that many >appear to be >recommending a switch to ECC because of the exponentially rising >power/cpu costs >for larger RSA sizes (e.g. NSA Suite B). The current text encourages being able to verify at any level, not just 1024 or even 2048. >So I would suggest making 2048 and smaller mandatory. And using a >sentence like: >" Note that receiving agents may see signatures whose key length is >longer than >2048 > bits in the future, and support for lengths of 3072 and 4078 SHOULD >be provided > > to verify those signatures." I fully disagree. We are talking about interoperability here, not best practice. We should not be mandating that receivers be able to verify things that beyond what is mandated for signers. If you want to change the length of what signers are required to do, that's fine, I would want both sides to be accordance. But until then, saying "you must be able to verify something larger than what you can sign" doesn't make sense from an interoperability standpoint. Also, we should not mandate SHOULD-level requirements for particular size keys. For verification, specific bit-lengths are not important: it is the maximum key length. >Or > > "... for lengths up to and including 4078 SHOULD ..." > >to address optional support. This doesn't seem to be a good reading of RFC 2119. From owner-ietf-smime@mail.imc.org Fri May 2 14:56: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 957653A69A2 for ; Fri, 2 May 2008 14:56:37 -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 qSU3r0ctenib for ; Fri, 2 May 2008 14:56:36 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 851FC3A67F4 for ; Fri, 2 May 2008 14:56:36 -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 m42LhsNl086111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 14:43:54 -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 m42Lhsj3086110; Fri, 2 May 2008 14:43:54 -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 m42Lhorn086080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 2 May 2008 14:43:53 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 2 May 2008 14:43:47 -0700 To: ietf-smime@imc.org From: Paul Hoffman Subject: RE: S/MIME v3.2 IDs key size text 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 6:16 AM +1200 5/3/08, Peter Gutmann wrote: >"Turner, Sean P." writes: > >>A receiving agent needs to be able to verify signatures whose key length is >>chosen by the signer. For interoperability, a receiving agent MUST be able to >>verify signatures whose key length is 1024 bits or shorter. > >[...] > >>Receiving agents are only required to validate signatures that are the same >>length as sending agents are required to produce, namely 1024 bits. > >Aren't these mutually exclusive? Yes; that's why they are in separate sections. >(The "or shorter" attached to the "1024" is also going to prove problematic >with FIPS-evaluated crypto implementations, since you can't do < 1024 bits for >those). That's just plain wrong. Nothing in the FIPS evaluation says that you cannot verify signatures shorter than what they require. From owner-ietf-smime@mail.imc.org Fri May 2 15:30: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 51C8D3A6913 for ; Fri, 2 May 2008 15:30:02 -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 ft4FVS86TwF1 for ; Fri, 2 May 2008 15:30:01 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 1FAA628C1D4 for ; Fri, 2 May 2008 15:29:49 -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 m42MHjan002023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 15:17: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 m42MHjIK002022; Fri, 2 May 2008 15:17: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.voltage.com (mail.voltage.com [209.213.222.98]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m42MHibt002008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 15:17:45 -0700 (MST) (envelope-from martin@voltage.com) Received: from hqmailsvr01.voltage.com (hqmailsvr01.voltage.com [172.16.0.22]) by mail.voltage.com (8.13.7/8.13.7) with ESMTP id m42MI5cE020651 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 2 May 2008 15:18:05 -0700 Received: from hqmailsvr01.voltage.com ([172.16.0.22]) by hqmailsvr01.voltage.com ([172.16.0.22]) with mapi; Fri, 2 May 2008 15:17:43 -0700 From: Luther Martin To: "'Paul Hoffman'" , "ietf-smime@imc.org" Date: Fri, 2 May 2008 15:17:43 -0700 Subject: RE: S/MIME v3.2 IDs key size text Thread-Topic: S/MIME v3.2 IDs key size text Thread-Index: AcisoRdLcJxLfqhgQJOqvCo62JIenQAAH5iw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=4.65.7161:2.4.4,1.2.40,4.0.164 definitions=2008-05-02_08:2008-05-02,2008-05-02,2008-05-02 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=1 spamscore=1 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=3.1.0-0804140000 definitions=main-0805020158 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > >(The "or shorter" attached to the "1024" is also going to prove > problematic > >with FIPS-evaluated crypto implementations, since you can't do < 1024 > bits for > >those). > > That's just plain wrong. Nothing in the FIPS evaluation says that you > cannot verify signatures shorter than what they require. I'm not sure that's accurate. A FIPS security policy is fairly clear about = exactly what keys and key sizes you can use in FIPS mode, and I'm fairly su= re that this stops you from using smaller keys in FIPS mode, even to verify= a signature. From owner-ietf-smime@mail.imc.org Fri May 2 16:00: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 64E2F3A6C6A for ; Fri, 2 May 2008 16:00:28 -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=[AWL=0.000, 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 cBUHVto2k2Kq for ; Fri, 2 May 2008 16:00:27 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 51A0F28C2A0 for ; Fri, 2 May 2008 15:59:45 -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 m42MkSOm014051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 15:46:28 -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 m42MkS9c014049; Fri, 2 May 2008 15:46:28 -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 m42MkND6014005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 15:46:25 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 2 May 2008 15:46:21 -0700 To: Luther Martin , "ietf-smime@imc.org" From: Paul Hoffman Subject: RE: S/MIME v3.2 IDs key size text 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 3:17 PM -0700 5/2/08, Luther Martin wrote: > > >(The "or shorter" attached to the "1024" is also going to prove >> problematic >> >with FIPS-evaluated crypto implementations, since you can't do < 1024 >> bits for >> >those). >> >> That's just plain wrong. Nothing in the FIPS evaluation says that you >> cannot verify signatures shorter than what they require. > >I'm not sure that's accurate. A FIPS security policy is fairly clear >about exactly what keys and key sizes you can use in FIPS mode, and >I'm fairly sure that this stops you from using smaller keys in FIPS >mode, even to verify a signature. That's quite different than what I said. In FIPS mode, you may need to only validate FIPS-mandated signatures (there is even some disagreement about this). However, a FIPS-evaluated system can also validate non-FIPS-mandated signatures, just not in FIPS mode (maybe). From owner-ietf-smime@mail.imc.org Fri May 2 22:22:35 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 5AE083A6774 for ; Fri, 2 May 2008 22:22:35 -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 K7p19Q6hPVpv for ; Fri, 2 May 2008 22:22:34 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 345B83A66B4 for ; Fri, 2 May 2008 22:22:33 -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 m434urP9078813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 21:56: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 m434urvi078812; Fri, 2 May 2008 21:56: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 mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m434ueQk078705; Fri, 2 May 2008 21:56:52 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id CC4374806D5; Sat, 3 May 2008 16:56:39 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTALaRLWIl4V; Sat, 3 May 2008 16:56:39 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id B2CF84806CF; Sat, 3 May 2008 16:56:39 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id BF5C119EC0B9; Sat, 3 May 2008 16:56:38 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1Js9na-00030Q-Lz; Sat, 03 May 2008 16:56:38 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org, phoffman@imc.org Subject: RE: S/MIME v3.2 IDs key size text In-Reply-To: Message-Id: Date: Sat, 03 May 2008 16:56:38 +1200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul Hoffman writes: >At 6:16 AM +1200 5/3/08, Peter Gutmann wrote: >>Aren't these mutually exclusive? > >Yes; that's why they are in separate sections. How does this reconcile them? Do we get to choose which ones we want? >>(The "or shorter" attached to the "1024" is also going to prove problematic >>with FIPS-evaluated crypto implementations, since you can't do < 1024 bits >>for those). > >That's just plain wrong. Nothing in the FIPS evaluation says that you cannot >verify signatures shorter than what they require. I didn't say you couldn't verify sigs, I said you couldn't get the code to do that evaluated because the minimum they'll accept is 1024 bits. In other words you'd be using non-evaluated code (or code run in a non-evaluated mode) to do the sig. verification. Peter. From owner-ietf-smime@mail.imc.org Sat May 3 09:11: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 EFD733A68F9 for ; Sat, 3 May 2008 09:11:03 -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 fmoHWS-yOtwd for ; Sat, 3 May 2008 09:11:03 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id D6FB83A6D24 for ; Sat, 3 May 2008 09:11:02 -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 m43Fnltj079961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2008 08:49: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 m43Fnlcq079960; Sat, 3 May 2008 08:49: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 [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 m43FnQAv079815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2008 08:49:27 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sat, 3 May 2008 08:49:25 -0700 To: pgut001@cs.auckland.ac.nz (Peter Gutmann), ietf-smime@imc.org From: Paul Hoffman Subject: RE: S/MIME v3.2 IDs key size text Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 4:56 PM +1200 5/3/08, Peter Gutmann wrote: >How does this reconcile them? Do we get to choose which ones we want? You follow the MUST, not the "if you care about doing things flexibly, you also do this". This is the same as for almost any IETF standard. > >>(The "or shorter" attached to the "1024" is also going to prove problematic >>>with FIPS-evaluated crypto implementations, since you can't do < 1024 bits >>>for those). >> >>That's just plain wrong. Nothing in the FIPS evaluation says that you cannot >>verify signatures shorter than what they require. > >I didn't say you couldn't verify sigs, I said you couldn't get the code to do >that evaluated because the minimum they'll accept is 1024 bits. In other >words you'd be using non-evaluated code (or code run in a non-evaluated mode) >to do the sig. verification. I admit that I haven't gone through a FIPS evaluation myself, but what you say seems wrong. .I assume that verifying code does not have different code paths for different sizes of keys being verified, so the evaluated code works for the mandated sizes and others. Even if you structured your code along key sizes, the "wrong" sizes would be non-evaluated, and the "right" sizes would be evaluated. If someone from NIST or from a test lab wants to chime in here, that would be grand. From owner-ietf-smime@mail.imc.org Sat May 3 11:33:30 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 0ED9A3A693C for ; Sat, 3 May 2008 11:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_20=-0.74, MIME_BASE64_BLANKS=0.041] 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 PejGU6pKkzaH for ; Sat, 3 May 2008 11:33:23 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 995993A685D for ; Sat, 3 May 2008 11:33: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 m43I8kFl039561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2008 11:08:46 -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 m43I8j6x039560; Sat, 3 May 2008 11:08: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-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 m43I8iLx039522; Sat, 3 May 2008 11:08:45 -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 1JsMA5-0001MT-33; Sat, 03 May 2008 14:08:42 -0400 From: "Tony Capel" To: "'Paul Hoffman'" , Subject: RE: S/MIME v3.2 IDs key size text Date: Sat, 3 May 2008 14:08:38 -0400 Message-ID: <000801c8ad48$b6b7f9a0$02b5a8c0@tony> MIME-Version: 1.0 Content-Type: application/pkcs7-mime; smime-type=signed-data; name="smime.p7m" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7m" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6838 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: AcisnoQIC2w21EFkR9aMbnt2Mc3yWgApnC8g Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEU0NvbnRl bnQtVHlwZTogdGV4dC9wbGFpbjsNCgljaGFyc2V0PSJ1cy1hc2NpaSINCkNvbnRlbnQtVHJhbnNm ZXItRW5jb2Rpbmc6IDdiaXQNCg0KBIIVTw0KUGF1bDoNCg0KMUEpIEJvdGggc2lnbmluZyBhbmQg dmVyaWZ5aW5nLg0KDQpWZXJpc2lnbiBoYXMgYmVlbiBpc3N1aW5nIGJvdGggMWsgYW5kIDJrIHNp bmdsZSBrZXlwYWlyIGNlcnRzIGZvciBzb21lDQp0aW1lLCAyayBpcyBiZWNvbWluZyBjb21tb24g aW4gbWFueSBwcm9kdWN0IHNwZWNpZmljYXRpb25zIGFuZCByZWNvbW1lbmRlZA0KYnkgbWFueSBy ZXB1dGFibGUgYXV0aG9yaXRpZXMuDQoNCkkgY29tbXVuaWNhdGUgdG9kYXkgd2l0aGluIGEgY29t bXVuaXR5IG9mIDJrIGFuZCBsb3dlciBjZXJ0aWZpY2F0ZSBob2xkZXJzDQpub3QgMUsgYW5kIGxv d2VyIGhvbGRlcnMuICBJIGhhdmUgYSAyayAib2ZmLXRoZS1zaGVsZiIgY2VydCBmcm9tIFZlcmlz aWduLA0KSSBjYW5ub3QgZ2VuZXJhdGUgMWsgc2lnbmF0dXJlcywgc28gYW55b25lIEkgc2VuZCB0 byBtdXN0IGJlIGFibGUgdG8NCnZlcmlmeSAyayBzaWduYXR1cmVzLiAgU28gdmVyaWZ5IDJrIHN1 cHBvcnQgaXMgcmVxdWlyZWQgdG9kYXkuICBJdCBpcyB0cnVlDQp0aGF0IHVzZXJzIHdobyBvbmx5 IGludGVuZCB0byB1c2UgMWsgY2VydHMgY291bGQgZ2V0IGF3YXkgd2l0aCBzb2Z0d2FyZQ0Kd2hp Y2ggY2Fubm90IHNpZ24gdXNpbmcgMmsga2V5czsgYnV0IEkgdGhpbmsgdGhpcyBpcyBhIHByZXR0 eSBzdWJ0bGUNCmRldGFpbCB3aGljaCB3b3VsZCBiZSBsb3N0IGluIHRoZSBub2lzZSBvZiBtb3N0 IHNwZWNpZmljYXRpb25zLg0KDQoxQikgQW5kIGVuY3J5cHRpb24gYW5kIGRlY3J5cHRpb24gYXMg d2VsbC4NCg0KRnVydGhlcm1vcmUsIHNpbmNlIHRob3NlIFZlcnNpZ24gY2VydHMgYXJlIHNpbmds ZSBrZXlwYWlyLCBJIG5lZWQgMmsNCmVuY3J5cHQvZGVjcnlwdCBzaW5jZSBvYnZpb3VzbHkgdGhl IHNhbWUga2V5cGFpciBpcyB1c2VkLiAgVGhvc2UgdXNpbmcNCm11bHRpcGxlIGtleXBhaXIgaW5m cmFzdHJ1Y3R1cmVzIHdpdGggc2VwYXJhdGUgc2lnbmluZyBhbmQgZW5jcnlwdGlvbg0KY2VydHMg Y291bGQgdXNlIGRpZmZlcmluZyBzaXplcywgYnV0IGluIG15IGV4cGVyaWVuY2UgdGhlIGluZnJh c3RydWN0dXJlcw0KdGhlbXNlbHZlcyB0ZW5kIHRvIGhhdmUgdGhlIHNhbWUgc3BlY2lmaWNhdGlv biBmb3IgYm90aCBzaWduIGFuZCBlbmNyeXB0DQooc2lnbi92ZXJpZnkgYW5kIGRlY3J5cHQvZW5j cnlwdCkuDQoNCkZvciBlbmNyeXB0aW9uIG9mIGNvdXJzZSB0aGUga2V5c2l6ZSBpcyBzcGVjaWZp ZWQgYnkgdGhlIGRlc3RpbmF0aW9uIGNlcnQ7DQpzbyBpZiBhbnlvbmUgaW4gbXkgY29tbXVuaXR5 IGhhcyAyayBrZXlzLCBJIG11c3QgYmUgYWJsZSB0byBlbmNyeXB0IHdpdGgNCjJrIGtleXMuICBT byBlbmNyeXB0IHN1cHBvcnQgZm9yIDJrIGtleXMgaXMgcmVxdWlyZWQgdG9kYXkuICBBZ2Fpbiwg MWsNCm9ubHkgc3VwcG9ydCBmb3IgZGVjcnlwdGlvbiB3b3VsZCBiZSBsb3N0IGluIHRoZSBub2lz ZS4NCg0KU28gaWYgd2Ugd2lzaCB0byBndWFyYW50ZWUgYSBtaW5pbXVtIGxldmVsIG9mICJvdXQt b2YtdGhlLWJveCINCmludGVyb3BlcmFiaWxpdHkgZnJvbSBhIGJveCB3aGljaCBoYXMgYSBzaW1w bGlzdGljIHNwZWNpZmljYXRpb24NCiJjb21wbGlhbnQgdG8gc21pbWUgdjMuMiI7IHRoZW4gd2Ug c2hvdWxkIGluY2x1ZGUgYSBtYW5kYXRlIGZvciAyayBhbmQNCmxvd2VyIHN1cHBvcnQgZm9yIGFs bCBvcGVyYXRpb25zIHRvIG1lZXQgdG9kYXkncyByZXF1aXJlbWVudC4NCg0KMikgU3VwcG9ydCBi ZXlvbmQgdGhlIG1hbmRhdG9yeS4NCg0KSSBhZ3JlZSB0aGF0IHN1cHBvcnQgYmV5b25kIDJrIHNo b3VsZCBiZSBvcHRpb25hbC4gIEkgYW0gc29ycnkgSSBtaXN1c2VkDQp0aGUgd29yZCAiU0hPVUxE IiwgSSBvcGVyYXRlIGluIHNldmVyYWwgc3RhbmRhcmRpemF0aW9uIGFyZW5hcyBhbmQgcmZjMjEx OQ0KaXMgbm90IGEgdW5pdmVyc2FsIHN0YW5kYXJkISEgIEkgbWVhbnQgT1BUSU9OQUwgb3IgTUFZ IGZvciB0aGUgbGFyZ2VyDQpzaXplcy4NCg0KVGhlIHJlYXNvbiBmb3IgbXkgaWRlbnRpZnlpbmcg dGhlIHNwZWNpZmljIDNrIGFuZCA0ayB2YWx1ZXMgd2FzIGFuIGF0dGVtcHQNCnRvIGFkZHJlc3Mg YW4gZWFybGllciB0aHJlYWQgd2hlcmUgNGsgYW5kIGxhcmdlciBrZXlzaXplcyB3ZXJlIHByb3Bv c2VkIC0NCndoaWNoIGxlZCB0byBhIGRpc2N1c3Npb24gb2YgZGVuaWFsIG9mIHNlcnZpY2UgYXR0 YWNrcyBieSBzZW5kZXJzDQpzcGVjaWZ5aW5nIGxhcmdlIGtleXNpemVzIC0gYW5kIHRoZW4gdGhp cyBsZWQgdG8gY29tbWVudHMgYWJvdXQgaW1wcm9wZXINCm1vZHVsdXMgc2VsZWN0aW9uLCBldGMu IGV0Yy4uLi4NCg0KVGhlIG9yaWdpbiBvZiB0aGUgZWFybGllciB0aHJlYWQgd2FzIGNvbmNlcm4g YWJvdXQgbGVhdmluZyBsYXJnZXIga2V5c2l6ZXMNCmNvbXBsZXRlbHkgb3BlbiAoZXZlbiBhcyBP UFRJT05BTCkuIEkgcHJlZmVyIHRvIGxlYXZlIHRoaXMgaXNzdWUsIGlmIGl0DQpyZW1haW5zIGFu IGlzc3VlLCB0byBQZXRlciBhbmQgdGhlIG90aGVycyB3aG8gY29udHJpYnV0ZWQgdG8gdGhhdCB0 aHJlYWQuDQooSSB3b3VsZCBqdXN0IG5vdGUgdGhhdCBpbiBteSByZWFkaW5nIDNrIGFuZCA0ayBj ZXJ0cyBhcmUgbWVudGlvbmVkLCBidXQNCml0IGlzIG5vdCBjbGVhciB0byBtZSB0aGF0IHRoZXJl IGlzIGEgZnV0dXJlIGJleW9uZCA0ayBSU0Egd2l0aA0KY29tcGV0aXRpb24gZnJvbSBvdGhlciBh bGdvcml0aG1zLikNCg0KVG9ueQ0KDQp8IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQp8IEZy b206IG93bmVyLWlldGYtc21pbWVAbWFpbC5pbWMub3JnDQp8IFttYWlsdG86b3duZXItaWV0Zi1z bWltZUBtYWlsLmltYy5vcmddIE9uIEJlaGFsZiBPZiBQYXVsIEhvZmZtYW4NCnwgU2VudDogTWF5 IDIsIDIwMDggNTo0NCBQTQ0KfCBUbzogaWV0Zi1zbWltZUBpbWMub3JnDQp8IFN1YmplY3Q6IFJF OiBTL01JTUUgdjMuMiBJRHMga2V5IHNpemUgdGV4dA0KfA0KfA0KfA0KfCBBdCAyOjM1IFBNIC0w NDAwIDUvMi8wOCwgVG9ueSBDYXBlbCB3cm90ZToNCnwgPkkgdGhpbmsgdGhlIG1pbmltdW0gc3Vw cG9ydGVkIHNpemUgbmVlZHMgdG8gYmUgMjA0OCBiZWNhdXNlOg0KfA0KfCBQbGVhc2UgYmUgbW9y ZSBzcGVjaWZpYy4gU3VwcG9ydGVkIGZvciB3aGF0PyBTaWduaW5nLA0KfCB2ZXJpZnlpbmcsIG9y IGJvdGg/DQp8DQp8ID4xKSBTaW5jZSBhdCBsZWFzdCBBcHJpbCAyMDA3IChvdmVyIGEgeWVhciBh Z28pIFZlcmlzaWduIGhhcyBiZWVuDQp8ID5pc3N1aW5nIGNlcnRzIHdpdGggMjA0OCBrZXlzIChJ IGJlbGlldmUgdGhpcyBpcyBzZWxlY3RhYmxlIHdoZW4NCnwgPmVucm9sbGluZykgKGFsdGhvdWdo IHRoZSByb290IGNlcnQgaXMgb25seSAxMDI0ISkuDQp8ID4yKSBOSVNUIGlzIHJlY29tbWVuZGlu ZyAyMDQ4IGJ5IGVuZCBvZiAyMDA4IGZvciBzaWduYXR1cmVzIGFuZCBrZXkNCnwgPnRyYW5zcG9y dCBmb3INCnwgPnNvbWUgYXBwcyBbU1AtODAwLTc4LTEgVGFibGUgMy4xXS4NCnwgPjMpIE1hbnkv bW9zdCBoYXJkd2FyZSB0b2tlbnMgKGUuZy4gU2FmZW5ldCwgR2VtLCBBbGFkZGluKQ0KfCBhcmUg c3VwcG9ydGluZyAxMDI0DQp8ID5hbmQgMjA0OCAob25seSkuDQp8DQp8IFRoZSB3b3JkaW5nIGNs ZWFybHkgc2F5cyB0aGF0IHlvdSBzaG91bGQgZXhwZWN0IHRvIHZhbGlkYXRlIGxhcmdlcg0KfCBr ZXlzLCB3aGljaCBhcmUgY292ZXJlZCBieSB0aG9zZSB0aHJlZSBkYXRhIHBvaW50cy4NCnwNCnwg WW91ciBsYXN0IHBvaW50IChoYXJkd2FyZSB0b2tlbnMgc2lnbmluZyBhdCAxMDI0KSBpcyBleGFj dGx5IHdoeSBJDQp8IHRoaW5rIG1hbmRhdGluZyB0aGUgYWJpbGl0eSB0byBzaWduIGF0IGxlYXN0 IDEwMjQgYml0cyBpcyBhIGdvb2QgaWRlYS4NCnwNCnwgPkFzIGZhciBhcyBnb2luZyBsYXJnZXIg dGhhbiAyMDQ4LCBpbiBteSBicmllZiBzdXJ2ZXksIHdoaWxlIHRoZXJlDQp8ID5hcHBlYXJzIHRv IGJlDQp8ID5hIHNtYWxsIGxldmVsIG9mIGludGVyZXN0IGluIDMwNzIgKGFuZCBldmVuIDQwOTYp LCBiZXlvbmQgdGhhdCBtYW55DQp8ID5hcHBlYXIgdG8gYmUNCnwgPnJlY29tbWVuZGluZyBhIHN3 aXRjaCB0byBFQ0MgYmVjYXVzZSBvZiB0aGUgZXhwb25lbnRpYWxseSByaXNpbmcNCnwgPnBvd2Vy L2NwdSBjb3N0cw0KfCA+Zm9yIGxhcmdlciBSU0Egc2l6ZXMgKGUuZy4gTlNBIFN1aXRlIEIpLg0K fA0KfCBUaGUgY3VycmVudCB0ZXh0IGVuY291cmFnZXMgYmVpbmcgYWJsZSB0byB2ZXJpZnkgYXQg YW55IGxldmVsLCBub3QNCnwganVzdCAxMDI0IG9yIGV2ZW4gMjA0OC4NCnwNCnwgPlNvIEkgd291 bGQgc3VnZ2VzdCBtYWtpbmcgMjA0OCBhbmQgc21hbGxlciBtYW5kYXRvcnkuIEFuZCB1c2luZyBh DQp8ID5zZW50ZW5jZSBsaWtlOg0KfCA+IiBOb3RlIHRoYXQgcmVjZWl2aW5nIGFnZW50cyBtYXkg c2VlIHNpZ25hdHVyZXMgd2hvc2Uga2V5IGxlbmd0aCBpcw0KfCA+bG9uZ2VyIHRoYW4NCnwgPjIw NDgNCnwgPiAgYml0cyBpbiB0aGUgZnV0dXJlLCBhbmQgc3VwcG9ydCBmb3IgbGVuZ3RocyBvZiAz MDcyIGFuZA0KfCA0MDc4IFNIT1VMRA0KfCA+YmUgcHJvdmlkZWQNCnwgPg0KfCA+ICB0byB2ZXJp ZnkgdGhvc2Ugc2lnbmF0dXJlcy4iDQp8DQp8IEkgZnVsbHkgZGlzYWdyZWUuIFdlIGFyZSB0YWxr aW5nIGFib3V0IGludGVyb3BlcmFiaWxpdHkgaGVyZSwgbm90DQp8IGJlc3QgcHJhY3RpY2UuIFdl IHNob3VsZCBub3QgYmUgbWFuZGF0aW5nIHRoYXQgcmVjZWl2ZXJzIGJlIGFibGUgdG8NCnwgdmVy aWZ5IHRoaW5ncyB0aGF0IGJleW9uZCB3aGF0IGlzIG1hbmRhdGVkIGZvciBzaWduZXJzLiBJZiB5 b3Ugd2FudA0KfCB0byBjaGFuZ2UgdGhlIGxlbmd0aCBvZiB3aGF0IHNpZ25lcnMgYXJlIHJlcXVp cmVkIHRvIGRvLCB0aGF0J3MgZmluZSwNCnwgSSB3b3VsZCB3YW50IGJvdGggc2lkZXMgdG8gYmUg YWNjb3JkYW5jZS4gQnV0IHVudGlsIHRoZW4sIHNheWluZyAieW91DQp8IG11c3QgYmUgYWJsZSB0 byB2ZXJpZnkgc29tZXRoaW5nIGxhcmdlciB0aGFuIHdoYXQgeW91IGNhbiBzaWduIg0KfCBkb2Vz bid0IG1ha2Ugc2Vuc2UgZnJvbSBhbiBpbnRlcm9wZXJhYmlsaXR5IHN0YW5kcG9pbnQuDQp8DQp8 IEFsc28sIHdlIHNob3VsZCBub3QgbWFuZGF0ZSBTSE9VTEQtbGV2ZWwgcmVxdWlyZW1lbnRzIGZv ciBwYXJ0aWN1bGFyDQp8IHNpemUga2V5cy4gRm9yIHZlcmlmaWNhdGlvbiwgc3BlY2lmaWMgYml0 LWxlbmd0aHMgYXJlIG5vdCBpbXBvcnRhbnQ6DQp8IGl0IGlzIHRoZSBtYXhpbXVtIGtleSBsZW5n dGguDQp8DQp8ID5Pcg0KfCA+DQp8ID4gICIuLi4gZm9yIGxlbmd0aHMgdXAgdG8gYW5kIGluY2x1 ZGluZyA0MDc4IFNIT1VMRCAuLi4iDQp8ID4NCnwgPnRvIGFkZHJlc3Mgb3B0aW9uYWwgc3VwcG9y dC4NCnwNCnwgVGhpcyBkb2Vzbid0IHNlZW0gdG8gYmUgYSBnb29kIHJlYWRpbmcgb2YgUkZDIDIx MTkuDQp8DQoEAAAAAAAAAKCCClIwggTMMIIENaADAgECAhAcrp1rmvTmLyKKo9p0YWweMA0GCSqG SIb3DQEBBQUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UE CxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNTEw MjgwMDAwMDBaFw0xNTEwMjcyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDJ36zn 6vj4AxTEAJLVwX42wjzvfHIVy8CrjD0clc5vHhAsPwDtlybmtsfmrUMdP6SHR0dMPlT4bPjH/LGe vTBwvJexAwXqlfGtQMVEeksFovJg/Nc6ZWLv/xB7ola7xU5wLdaiHzztsELoXo1XIaymmdkR6dIa B8B0R0IL/MU06v3muiTRHQgVN6LXc88BQS9jsjo/vqUabvTJSls9laYVuzUCGfnU77yPDnF2WbtL tj7W/FoW9NYOifJJ/mwM7RXp2Yh1nHnOYCfdua11zi9zlXpAOoV1SbC432i8q80TgoURUKPgPAuu wApTzdcwb4UyRhvkSRDCbOKvH3n/27S1AgMBAAGjggGEMIIBgDASBgNVHRMBAf8ECDAGAQH/AgEA MEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWk IzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps 1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2Ex LmNybDCBgQYDVR0jBHoweKFjpGEwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5ghEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQUFAAOBgQCxL9mW4ZKi7oFg5cgqIPvh ZyzWAJhTowIb6ZBL+BhEnw9G9/qg/tMdGKPSvxzs1hmfSk1D+Mq7vhOASQXdIXMzV8JCWr76AJOy 5gQxkU5dPPBzBTdj67+DWZj9Zt7phjKakik8Oq5U2qYSUbGPyMrTR3jm26Uehwbj0RTAwiH2ujCC BX4wggRmoAMCAQICEESSWjobm8B74KlIfva/2j8wDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0 d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y cGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjAeFw0wODA0MTcwMDAwMDBa Fw0wOTA0MjAyMzU5NTlaMIIBFTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90 IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBT ZXJ2aWNlMRowGAYDVQQDFBFBLkMuIChUb255KSBDYXBlbDEgMB4GCSqGSIb3DQEJARYRY2FwZWxA Y29tZ2F0ZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtfsxOpz6QFfItcBlg xYSH9UbbQaogvaigfZAV45h+fnjVJ+n2zUA6XHOx7XwRZt8EgFcA4aSthXF3evO8DVqKBZcwwBcN 7ylVioSRlDD/TUvXScF+Uh77iC9+9cCN5+mWtNcf1rrBu3pLpViYObKS65JwxinyF9t2AhOLbkVZ hs7b9aKQHq6qAMvQhskxzfdr404pJUKVJ7gGoZOOv1uA3KQdKszXvkG5plO3eNNTaG74JyXTVuLE w/5/RDfaEtD3ayNSBozXWFoGkkD6qCMYtVYhbZFe1JFHU9eJT5Ps5cNmQ3qT43iM/96lqs81f8or ERTHMSvOt0gEJx02eRqZAgMBAAGjgf4wgfswCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG +EUBBxcDMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0P BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAwBgpghkgBhvhFAQYHBCIWIDcx NThjMjkzOGUyZDFkMGRkMTljMTA0MzAyN2QzYjFlMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9J bmRDMURpZ2l0YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDANBgkqhkiG 9w0BAQUFAAOCAQEApfrZkVZZ2pIl60wajeIbTEMslpmB3iHiD7joNe73Ipw+CWfhKKK/kmaSxSRH aKuIOsS2YMM4NHUQkdDA+/BRpBpVHEvdoghwsMh1RLmElt6iQcbnMCNVxvC/36F5loFfSp4TRTVJ GX+EH6It+F4faK88hEQXNNytqLQMHdgX6XSZlnj3M2BhhMUHkxNl7GPNHEkhOQK1J/x7bTx5YgoM pks8eKeO+tuM3GUYeGvy8SsOuWf+1hDaMotfIASiz1Y0z6CL/NImCFhOmMIO9R8z4HitRU5/MFsO lyxcGtxUbp+S9tDJ0bVCNhqvViIgnxCWJ8s4iguwImF4qviYNE9TCzGCBPQwggTwAgEBMIHyMIHd MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNV BAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEESSWjob m8B74KlIfva/2j8wCQYFKw4DAhoFAKCCAtYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDgwNTAzMTgwODM3WjAjBgkqhkiG9w0BCQQxFgQUIaMpec9DF9aLMxAkAs1f qEuUBQYwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAHBgUrDgMCGjAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwCgYIKoZIhvcNAgUwggED BgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNj cmliZXIgQ0EgLSBHMgIQRJJaOhubwHvgqUh+9r/aPzCCAQUGCyqGSIb3DQEJEAILMYH1oIHyMIHd MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNV BAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEESSWjob m8B74KlIfva/2j8wDQYJKoZIhvcNAQEBBQAEggEAQ1TJf8EYPBfuElsfR+POqJaAJQ+lddH7GVDE 8JsYJOJODQIfdW9EgbrX69A89DJzLe6HNIZ3LIXg3V89F+xOWvEN5lyAz1uJDjwEZiCu1YQm0kpR f5AbGDcgshkiiedeAbhDtsFVk5GKFaYbkEB7aNQ6/89VA2A3SlCzjy0PyIL9bGPUzCqfm0O3YWVu UKb2+tegh9v6Rc8aofk42pKW282AKhTMXGm5eOyvymwkDVmBgrCW6qpS06h5m7b3sqx/w7rljflJ E/PyZ0YkU+19Za4AmIHA6K7Vo7Ipf/chyNe4UroTgEBEaVOE0DcqNZtesADfvtvoPHfYfz1j5NiE FgAAAAAAAA== From owner-ietf-smime@mail.imc.org Sat May 3 12:10: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 120E43A6831 for ; Sat, 3 May 2008 12:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=0.475, 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 PbNjzlBPQPey for ; Sat, 3 May 2008 12:10:18 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 6533C3A69FF for ; Sat, 3 May 2008 12:10:17 -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 m43Io2xV058953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2008 11:50:02 -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 m43Io2oY058952; Sat, 3 May 2008 11:50:02 -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-08.primus.ca (mail.tor.primus.ca [216.254.136.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m43Io1Jt058923; Sat, 3 May 2008 11:50:01 -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-08.primus.ca with esmtps (TLSv1:RC4-MD5:128) (Exim 4.63) (envelope-from ) id 1JsMo4-0004iP-1k; Sat, 03 May 2008 14:50:00 -0400 From: "Tony Capel" To: "'Paul Hoffman'" , Subject: RE: S/MIME v3.2 IDs key size text (resend, this time not opaque signed with 2k key) Date: Sat, 3 May 2008 14:49:57 -0400 Message-ID: <001801c8ad4e$7c0bc6a0$02b5a8c0@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: Importance: Normal Thread-Index: AcisnoQIC2w21EFkR9aMbnt2Mc3yWgArqPAg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul: 1A) Both signing and verifying. Verisign has been issuing both 1k and 2k single keypair certs for some time, 2k is becoming common in many product specifications and recommended by many reputable authorities. I communicate today within a community of 2k and lower certificate holders not 1K and lower holders. I have a 2k "off-the-shelf" cert from Verisign, I cannot generate 1k signatures, so anyone I send to must be able to verify 2k signatures. So verify 2k support is required today. It is true that users who only intend to use 1k certs could get away with software which cannot sign using 2k keys; but I think this is a pretty subtle detail which would be lost in the noise of most specifications. 1B) And encryption and decryption as well. Furthermore, since those Versign certs are single keypair, I need 2k encrypt/decrypt since obviously the same keypair is used. Those using multiple keypair infrastructures with separate signing and encryption certs could use differing sizes, but in my experience the infrastructures themselves tend to have the same specification for both sign and encrypt (sign/verify and decrypt/encrypt). For encryption of course the keysize is specified by the destination cert; so if anyone in my community has 2k keys, I must be able to encrypt with 2k keys. So encrypt support for 2k keys is required today. Again, 1k only support for decryption would be lost in the noise. So if we wish to guarantee a minimum level of "out-of-the-box" interoperability from a box which has a simplistic specification "compliant to smime v3.2"; then we should include a mandate for 2k and lower support for all operations to meet today's requirement. 2) Support beyond the mandatory. I agree that support beyond 2k should be optional. I am sorry I misused the word "SHOULD", I operate in several standardization arenas and rfc2119 is not a universal standard!! I meant OPTIONAL or MAY for the larger sizes. The reason for my identifying the specific 3k and 4k values was an attempt to address an earlier thread where 4k and larger keysizes were proposed - which led to a discussion of denial of service attacks by senders specifying large keysizes - and then this led to comments about improper modulus selection, etc. etc.... The origin of the earlier thread was concern about leaving larger keysizes completely open (even as OPTIONAL). I prefer to leave this issue, if it remains an issue, to Peter and the others who contributed to that thread. (I would just note that in my reading 3k and 4k certs are mentioned, but it is not clear to me that there is a future beyond 4k RSA with competition from other algorithms.) Tony | -----Original Message----- | From: owner-ietf-smime@mail.imc.org | [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Paul Hoffman | Sent: May 2, 2008 5:44 PM | To: ietf-smime@imc.org | Subject: RE: S/MIME v3.2 IDs key size text | | | | At 2:35 PM -0400 5/2/08, Tony Capel wrote: | >I think the minimum supported size needs to be 2048 because: | | Please be more specific. Supported for what? Signing, | verifying, or both? | | >1) Since at least April 2007 (over a year ago) Verisign has been | >issuing certs with 2048 keys (I believe this is selectable when | >enrolling) (although the root cert is only 1024!). | >2) NIST is recommending 2048 by end of 2008 for signatures and key | >transport for | >some apps [SP-800-78-1 Table 3.1]. | >3) Many/most hardware tokens (e.g. Safenet, Gem, Aladdin) | are supporting 1024 | >and 2048 (only). | | The wording clearly says that you should expect to validate larger | keys, which are covered by those three data points. | | Your last point (hardware tokens signing at 1024) is exactly why I | think mandating the ability to sign at least 1024 bits is a good idea. | | >As far as going larger than 2048, in my brief survey, while there | >appears to be | >a small level of interest in 3072 (and even 4096), beyond that many | >appear to be | >recommending a switch to ECC because of the exponentially rising | >power/cpu costs | >for larger RSA sizes (e.g. NSA Suite B). | | The current text encourages being able to verify at any level, not | just 1024 or even 2048. | | >So I would suggest making 2048 and smaller mandatory. And using a | >sentence like: | >" Note that receiving agents may see signatures whose key length is | >longer than | >2048 | > bits in the future, and support for lengths of 3072 and | 4078 SHOULD | >be provided | > | > to verify those signatures." | | I fully disagree. We are talking about interoperability here, not | best practice. We should not be mandating that receivers be able to | verify things that beyond what is mandated for signers. If you want | to change the length of what signers are required to do, that's fine, | I would want both sides to be accordance. But until then, saying "you | must be able to verify something larger than what you can sign" | doesn't make sense from an interoperability standpoint. | | Also, we should not mandate SHOULD-level requirements for particular | size keys. For verification, specific bit-lengths are not important: | it is the maximum key length. | | >Or | > | > "... for lengths up to and including 4078 SHOULD ..." | > | >to address optional support. | | This doesn't seem to be a good reading of RFC 2119. | From owner-ietf-smime@mail.imc.org Sat May 3 12:36: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 97BF73A6DED for ; Sat, 3 May 2008 12:36:56 -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=[AWL=0.000, 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 UpjMRhWRmn8g for ; Sat, 3 May 2008 12:36:55 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 6FE353A6D3B for ; Sat, 3 May 2008 12:36: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 m43JBP5K067499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2008 12:11: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 m43JBPkm067498; Sat, 3 May 2008 12:11:25 -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 m43JBMWV067473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 3 May 2008 12:11:24 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <001801c8ad4e$7c0bc6a0$02b5a8c0@tony> References: <001801c8ad4e$7c0bc6a0$02b5a8c0@tony> Date: Sat, 3 May 2008 12:11:20 -0700 To: From: Paul Hoffman Subject: RE: S/MIME v3.2 IDs key size text (resend, this time not opaque signed with 2k key) 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:49 PM -0400 5/3/08, Tony Capel wrote: >1A) Both signing and verifying. > >Verisign has been issuing both 1k and 2k single keypair certs for some >time, 2k is becoming common in many product specifications and recommended >by many reputable authorities. How is this relevant to the discussion thread? There are lots of communities that use (and even require) higher security than what is in the current spec. For example, the US Department of Defense is now mandating the use of elliptic curve cryptography for digital signatures. Using them as the base, instead of VeriSign, we would have a mandatory-to-implement requirement for ECC. I do not imagine you would support that, so I don't see why picking one product (the 2K certs) from one vendor should affect our decision for the mandatory-to-implement requirements as long as we make it clear that it is likely that any application will probably want to do more than that. >So if we wish to guarantee a minimum level of "out-of-the-box" >interoperability from a box which has a simplistic specification >"compliant to smime v3.2"; then we should include a mandate for 2k and >lower support for all operations to meet today's requirement. This completely confuses mandatory-to-implement and optional. VeriSign uses one of the options available to them, namely longer key sizes. They also use the mandatory-to-implement size, and they still distribute their own certificates using much-lower-than-mandatory sizes. None of that is relevant to anyone other than VeriSign and their customers. Our task is to create a standard that is usable by as many people as possible while at the same time as setting some minimum operational security expectations. For interoperability, we need to say "you can verify signatures created following this spec". For minimum operational security, we have to pick a size that is reasonable for the vast majority of users while encouraging software developers to support all reasonable sizes. Please read RFC 3766. If you believe that the numbers in there are wrong, by all means let the IETF community know. If you believe that the numbers there are right but you still think that a typical user needs more than 75 bits of symmetric strength for their signatures, even though no one has ever done that much effort for even a single attack in public, please say why. From owner-ietf-smime@mail.imc.org Sat May 3 16:37: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 564733A6845 for ; Sat, 3 May 2008 16:37:32 -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 lCSi25dM6wgQ for ; Sat, 3 May 2008 16:37:30 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 201D33A67D5 for ; Sat, 3 May 2008 16:37: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 m43MqNqj067312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2008 15:52: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 m43MqNRN067311; Sat, 3 May 2008 15:52: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 smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m43MqLmU067293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 3 May 2008 15:52:22 -0700 (MST) (envelope-from ietf@augustcellars.com) Received: from GALATIONS (unknown [207.202.179.27]) by smtp1.pacifier.net (Postfix) with ESMTP id 1521B6F184; Sat, 3 May 2008 15:52:19 -0700 (PDT) From: "Jim Schaad" To: "'Turner, Sean P.'" , "'Ietf-Smime'" References: <018301c8a3cb$38074bf0$0301a8c0@Wylie> In-Reply-To: <018301c8a3cb$38074bf0$0301a8c0@Wylie> Subject: RE: New ASN.1 modules comments/questions Date: Sat, 3 May 2008 15:52:19 -0700 Message-ID: <0fe601c8ad70$57e77c70$07b67550$@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: Acijyzeq0RMiwCJnRHiuFMdEY7uJtQJkneRg Content-Language: en-us Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sean, Sorry for the delay in getting back to you. I had some work that needed to get finished. Jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf- > smime@mail.imc.org] On Behalf Of Turner, Sean P. > Sent: Monday, April 21, 2008 9:18 AM > To: 'Ietf-Smime' > Subject: New ASN.1 modules comments/questions > > > Jim and Paul, > > Here are some comments/questions on the ASN.1 modules. > > spt > > ------------------- > > The definitions of AlgorithmIdentifier in the PKIX and SMIME modules > are > different - is there a reason for the difference? Does it matter? In > PKIX > it's AlgorithmSet, in SMIME it's InfoObjectSet, in RFC2976 it's IOSet, > in > ANSI X9 docs it's also IOSet, and in X.509 it's SupportedAlgorithms. If > it > matters, then I guess I lean towards what's in RFC2976 since it's > already in > an RFC. There is no effective difference between the two definitions. The two differences are 1) the name of a parameter and 2) comments. The name of the parameter makes no difference. Just as the name of a parameter makes no difference if you are writing a C function. The same is true for comments. > > ------------------- > > In the 3370 section, > > 1. Shouldn't AlgorithmIdentifier be imported from the PKIX module? Long term, AlgorithmIdentifier will be imported from the new Algorithm Information module. So this should become moot. > > 2. You used alg- as tag for hash algs, sig- for signature algs, kea- > for > key agreement algs, alg- for symmetric key encryption algs. I think it > might be easier to figure out which algs go where if the tag matches > the > type of algorithm like mda- for MessageDigestAlgorithms, sa- for > SignatureAlgorithms, and kaa- for KeyAgreementAlgorithms. Thanks for suggesting some potential tags to be used. I agree that we need some short simple notation to mark the different types of algorithm objects. > > 3. Could we change SymmetricKeyEncryptionAlgorithms to just > KeyWrapAlgorithms and use kwa- as the tag? There's also a > KeyWrapAlgorithm > that I think is supposed to be the same as the > SymmetricKeyEncryptionAlgorithms so one or the other can get deleted > (if you > delete the later change SupportKeyWrapAlgorithms to KeyWrapAlgorithms)? I have no problems with this change. There is a minor question here about doing a good job of distinguishing Key Wrap Algorithms and Key Transport Algorithms. I added the Symmetric to the front to distinguish from Key Transport algorithms which, as the KEA algorithm suggest, can also be thought of as Key Encryption algorithms. The use of Key Wrap might be sufficient to distinguish between them, but CMS uses Key Encryption as the name of these types of algorithms. Which is a better way to go? > > 4. Shouldn't SymmetricKeyEncryptionAlgorithms be extensible? > Welcome to a long philosophical discussion. There are two different places where this extensibility can be placed. The two different locations imply different things. This means that depending on how you look at things this should or should not be extensible. If you place the extensibility here, you are saying that we think that this document is going to be updated, and that we are going to add new algorithms to this document. Alternatively, if you place the extensibility in CMS, you are saying that we are going to define new algorithms by creating new documents with new modules and they should be "imported" into the CMS document in one manner or another. The compiler that we are working on has a planned directive to allow for an object to be added to an extensible object set. Part of the question at this point would be as follows. Where should the new algorithm be added, in this document - thus potentially effecting more than just CMS - or in CMS thus limiting where the changes are set. My personal beliefs are: - 1. New algorithms should be added by creating new documents not by updating this document - 2. Changes in algorithm sets should be as narrow as possible - thus the updates should be done in CMS not here. The upshot of this is that I believe this object set is NOT extensible, but the corresponding one in CMS should be extensible. > 5. Do we need to add a MessageAuthenticationCodeAlgorithms for the > hmac > alg? Then we could use maca- in front of the hMAC-SHA1. I have no issues with this. > > 6. Some of the IOSets are {...} (like SignatureAlgorithms) while > others > lists algorithms (like MessageDigestAlgorithms) - shouldn't all of them > list > algorithms or none? This has to do with the fact that the module updates are not finished, but the symbols needed to be defined for different reasons. These will become closed sets with the appropriate algorithm objects in them. > > ------------------- > > In the 3565 section, I think the algorithms need to be defined using > the new > syntax, import ALGORITHM, and define the algs as follows: > > ContentEncryptionAlgorithms ALGORITHM ::= { > cea-aes128-cbc | > cea-aes192-cbc | > cea-aes256-cbc, > ... -- Extensible > } > > cea-aes128-cbc ALGORITHM ::= { > OID id-aes128-CBC PARMS AES-IV } > > cea-aes192-cbc ALGORITHM ::= { > OID id-aes192-CBC PARMS AES-IV } > > cea-aes256-cbc ALGORITHM ::= { > OID id-aes256-CBC PARMS AES-IV } > > KeyWrapAlgorithms ALGORITHM ::= { > kwa-aes128 | > kwa-aes192 | > kwa-aes256, > ... -- Extensible > } > > kwa-aes128 ALGORITHM ::= { > OID id-aes128-wrap PARMS ABSENT } > > kwa-aes192 ALGORITHM ::= { > OID id-aes192-wrap PARMS ABSENT } > > kwa-aes256 ALGORITHM ::= { > OID id-aes256-wrap PARMS ABSENT } > Module has not be updated to reflect what is going on in modules. I was waiting to get the Algorithm Information module finished first. > ------------------- > > In the 3851 section, shouldn't SMimeAttributeSet be extensible? r/{ > attr-smimeCapabilities | attr-encrypKeyPref }/{ attr-smimeCapabilities > | > attr-encrypKeyPref, ... } See discussion above about whether we think we are going to add new attributes to a future version of this document. > > ------------------- > > In the 3852 section, > > 1. OID for PKIX1 module doesn't match the new PKIX asn ID OID - I > think it > should be id-pkix-explict(19) instead of (18). First, at some point we are going to replace all of the module numbers. We have just not yet gotten to that point. Based on the documents that I looked at, the explicit module is 18. > > 2. Are you going to remove the version notations [[3:, [[4:, etc? It is my belief that having the version tags included adds information to the ASN.1 module. Thus I plan on keeping them unless I get some large objections. > > 3. For consistency with 3370, can we change DigestAlgorithmList to > MessageDigestAlgorithms? I don't want these to have the same names. In the long run we will do the following: DigestAlgorithmList ALGORITHM ::= {MessageDigestAlgorithms,...} However I am open to the following: - We create a standardized but descriptive method of naming the sets of algorithms defined in a module - thus in 3370 we might say CMSAlgs-MessageDigestAlgorithm - Do the suggested re-name here. > > 4. For consistency, can we change UnsigedAttributes to > UnsignedAttributesSet and UnprotectedAttributes to > UnprotectedAttribuesSet? No problems > > 5. In AuthenticatedData, SupportedAttributes is used in AuthAttributes > and > UnauthAttributes. In AuthAttributes, can we change SupportAttributes to > AuthAttributesSet and in UnauthAttributes can we change > SupportedAttributes > to UnauthAttributesSet? No problems > > 6. For consistency with the 3370 section, can we change > SignatureAlgorithmList to SignatureAlgorithms, DigestAlgorithmList to > MessageDigestAlgorithms, KeyAgreementAlgorithmList to > KeyAgreementAlgorithms, and ContentEncryptionAlgorithmLists to > ContentEncryptionAlgorithms? See above note > > 7. Can we change KeyDerivationAlgorithmIdentifier to use > KeyDerivationAlgorithms instead of AlgorithmList? Yes this should be done. > > 8. Can we change MessageAuthenticationCodeAlgorithm to use > MessageAuthenticationCodeAlgorithms instead of AlgorithmList? > Yes this should be done > 9. Don't we want to define an OriginatorPKAlgorithms instead of using > AlgorithmList in OriginatorPublicKey: > > OriginatorPublicKey ::= SEQUENCE { > algorithm AlgorithmIdentifier {{OriginatorPKAlgorithms}}, > publicKey BIT STRING > } > > OriginatorPKAlgorithms ALGORITHM ::= { > ... -- Extensible > } > Yes this should be done in the end. > 10. For consistency, can we change KeyEncryptionAlgorithmList to be > KeyEncryptionAlgorithms? The above note about matching the name in 3370 needs to be taken into account. I used List (but could have used Set) but I am not wedded to this. I worry about using an 's' at the end as this could be a sequence of algorithms as well. There exists a potential confusion in the future. > > ------------------- > > In the 4108 section, can we make FirwareContentTypes and > FirmwareSignedAttrs > extensible? See discussion on the question - do we think this module will be updated in the future. > > ------------------- > > In the 4998 section, > > 1. Shouldn't we constrain the digestAlgorithms and digestAlgorithm? Probably - this is actually not a CMS module. I was waiting to figure out how algorithms are actually done first > > 2. Should the import for Attribute come from PKIX or RFC3852 update > module? This has been moved to the PKIX-COMMON module > > 3. Why is Extensions and EXTENSION imported? To use a single standardized version, as with Attribute > > ------------------- > > In the 5035 section, > > 1. Why is Extensions and EXTENSION imported? > See above > 2. Should the import for Attribute come from PKIX or RFC3852 update > module? > See above > 3. OID for PKIX1 module doesn't match the new PKIX asn ID OID - I > think it > should be id-pkix-explict(19) instead of (18). > See above note > 4. Should EssSignedAttributes be SignedAttributes? Should it also be > extensible? > See both above philosophy discussion and discussions on naming of items > 5. Should EssContentTypes be just ContentSet? > Same as above. > 6. Is the note about the identical SecurityCategories encoding > required > anymore? I have no opinion one way or the other on this. Being conservative says it stays. > > 7. Shouldn't we say HashAlgorithms ::= MessageDigestAlgorithms instead > of > HashAlgorithms ::= AlgorithmIdentifier {{...}}? Yes it should - it also needs to import it - which is a new module. > > 8. Shouldn't we import the shaa256 alg? > Yes - it would be wise - I did not do it originally so that I did not import a new module. > ------------------- > > In the 5084 section, we should import ALGORITHM from PKIX and define > the > algorithms as follows: > > ContentEncryptionAlgorithms ALGORITHM ::= { > cea-aes128-ccm | > cea-aes192-ccm | > cea-aes256-ccm | > cea-aes128-gcm | > cea-aes128-gcm | > cea-aes128-gcm, > ... -- Extensible > } > > cea-aes128-ccm ALGORITHM ::= { > OID id-aes128-CCM PARMS CCMParameters } > > cea-aes192-ccm ALGORITHM ::= { > OID id-aes192-CCM PARMS CCMParameters } > > cea-aes256-ccm ALGORITHM ::= { > OID id-aes256-CCM PARMS CCMParameters } > > cea-aes128-gcm ALGORITHM ::= { > OID id-aes128-GCM PARMS GCMParameters } > > cea-aes192-gcm ALGORITHM ::= { > OID id-aes192-GCM PARMS GCMParameters } > > cea-aes256-gcm ALGORITHM ::= { > OID id-aes256-GCM PARMS GCMParameters } This is waiting on the new Algoirthm Information module. From owner-ietf-smime@mail.imc.org Sat May 3 18:10: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 925383A69F3 for ; Sat, 3 May 2008 18:10:23 -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 mhOwAk11vnkQ for ; Sat, 3 May 2008 18:10:22 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 7090B3A69E7 for ; Sat, 3 May 2008 18:10: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 m440tW7c020023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2008 17:55: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 m440tWan020022; Sat, 3 May 2008 17:55: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 m440tU1a020007 for ; Sat, 3 May 2008 17:55:31 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 63842 invoked from network); 4 May 2008 00:55:30 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.231.117.153 with login) by smtp106.biz.mail.re2.yahoo.com with SMTP; 4 May 2008 00:55:29 -0000 X-YMail-OSG: 8suDOCEVM1lEXQ61q2tJO74g08pYt.mAn.sgbWhH.1iHMnpkmX2VIdKkR5QCVswTiGwOLeGYbG7wd7jldMrjuA45JHQyzSOsFiAe0BJvwXg8o2YiOLGBxeKDNDC_qKm7j.I- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: References: Subject: RE: S/MIME v3.2 IDs key size text Date: Sat, 3 May 2008 20:51:28 -0400 Organization: IECA, Inc. Message-ID: <000001c8ad81$00163160$0201a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acisn2OMVeAjgQKaRQq0PXBytb9a6AA4W3Jw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think if we struck ", namely 1024 bits" from the text in the security considerations that it's still a true statement and we won't have to change it every time we update the spec. spt >-----Original Message----- >From: owner-ietf-smime@mail.imc.org >[mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Paul Hoffman >Sent: Friday, May 02, 2008 5:44 PM >To: ietf-smime@imc.org >Subject: RE: S/MIME v3.2 IDs key size text > > >At 6:16 AM +1200 5/3/08, Peter Gutmann wrote: >>"Turner, Sean P." writes: >> >>>A receiving agent needs to be able to verify signatures whose key >>>length is chosen by the signer. For interoperability, a receiving >>>agent MUST be able to verify signatures whose key length is >1024 bits or shorter. >> >>[...] >> >>>Receiving agents are only required to validate signatures >that are the >>>same length as sending agents are required to produce, >namely 1024 bits. >> >>Aren't these mutually exclusive? > >Yes; that's why they are in separate sections. > >>(The "or shorter" attached to the "1024" is also going to prove >>problematic with FIPS-evaluated crypto implementations, since >you can't >>do < 1024 bits for those). > >That's just plain wrong. Nothing in the FIPS evaluation says >that you cannot verify signatures shorter than what they require. > From owner-ietf-smime@mail.imc.org Sat May 3 19:21:40 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 3BD8E3A67F6 for ; Sat, 3 May 2008 19:21:40 -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=[AWL=0.000, 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 e39KjlGTuxZ2 for ; Sat, 3 May 2008 19:21:39 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 342303A69A3 for ; Sat, 3 May 2008 19:21:38 -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 m4428I2j050371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2008 19:08:18 -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 m4428I5K050370; Sat, 3 May 2008 19:08:18 -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 m4428Er8050339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2008 19:08:16 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <000001c8ad81$00163160$0201a8c0@Wylie> References: <000001c8ad81$00163160$0201a8c0@Wylie> Date: Sat, 3 May 2008 19:08:13 -0700 To: "Turner, Sean P." , From: Paul Hoffman Subject: RE: S/MIME v3.2 IDs key size text Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 8:51 PM -0400 5/3/08, Turner, Sean P. wrote: >I think if we struck ", namely 1024 bits" from the text in the security >considerations that it's still a true statement and we won't have to change >it every time we update the spec. I'm OK with that, but I also feel that if we're updating the minimum mandatory signing length, it is trivial to update the Security Considerations as well. From owner-ietf-smime@mail.imc.org Sun May 4 01:13: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 274BA3A6DC3 for ; Sun, 4 May 2008 01:13:01 -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 jy4SmKNyNOL1 for ; Sun, 4 May 2008 01:13:00 -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 007B23A6E07 for ; Sun, 4 May 2008 01:12:59 -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 m447vr8S003254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 May 2008 00:57: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 m447vrWj003251; Sun, 4 May 2008 00:57: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 mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m447vl0c003194; Sun, 4 May 2008 00:57:52 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 4E64C4804A9; Sun, 4 May 2008 19:57:47 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4l2UCQ95zSPH; Sun, 4 May 2008 19:57:47 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 3076A4804A8; Sun, 4 May 2008 19:57:47 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id AC13A19EC0B9; Sun, 4 May 2008 19:57:46 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JsZ6Q-00057e-JF; Sun, 04 May 2008 19:57:46 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org, pgut001@cs.auckland.ac.nz, phoffman@imc.org Subject: RE: S/MIME v3.2 IDs key size text In-Reply-To: Message-Id: Date: Sun, 04 May 2008 19:57:46 +1200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul Hoffman writes: >At 4:56 PM +1200 5/3/08, Peter Gutmann wrote: >> >>(The "or shorter" attached to the "1024" is also going to prove problematic >>>>with FIPS-evaluated crypto implementations, since you can't do < 1024 bits >>>>for those). >>> >>>That's just plain wrong. Nothing in the FIPS evaluation says that you cannot >>>verify signatures shorter than what they require. >> >>I didn't say you couldn't verify sigs, I said you couldn't get the code to do >>that evaluated because the minimum they'll accept is 1024 bits. In other >>words you'd be using non-evaluated code (or code run in a non-evaluated mode) >>to do the sig. verification. > >I admit that I haven't gone through a FIPS evaluation myself, but what you >say seems wrong. I've gone through several, and talked to numerous others who have as well. It's the usual crapshoot, some labs will allow < 1024-bit keys and some won't. For my own code I've had one lab pass 512-bit keys OK and another one say that any ability to use keys of less than 1024 bits would mean it couldn't be evaluated. In another, more amusing case reported to me by someone else, they got one lab to OK it at 512 bits, then a second lab required them to submit paperwork showing that they blocked all keys of less than 1024 bits, and after they did that the first lab complained that they were failing their tests on 512-bit keys. In the end they just declared that their product didn't support any keys less than 1024 bits and everything was OK. >If someone from NIST or from a test lab wants to chime in here, that would be >grand. What really matters is what the labs in sum total enforce, not what NIST thinks or what one individual lab does. As the above examples show, you can jury-shop your lab to get 512-bit keys passed if you like, but it only works in some cases and to be safe you need to use a minimum key size of 1024 bits. Peter. From owner-ietf-smime@mail.imc.org Sun May 4 12:10:33 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 34DAD3A6841 for ; Sun, 4 May 2008 12:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=-0.277, 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 bhFtnWlNcGkR for ; Sun, 4 May 2008 12:10:23 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 50F6328C111 for ; Sun, 4 May 2008 12:09:41 -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 m44InWtP088243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 May 2008 11:49: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 m44InWeB088242; Sun, 4 May 2008 11:49: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 mail.voltage.com (mail.voltage.com [209.213.222.98]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m44InVVs088218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 May 2008 11:49:31 -0700 (MST) (envelope-from martin@voltage.com) Received: from hqmailsvr01.voltage.com (hqmailsvr01.voltage.com [172.16.0.22]) by mail.voltage.com (8.13.7/8.13.7) with ESMTP id m44InpPh000381 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 4 May 2008 11:49:51 -0700 Received: from hqmailsvr01.voltage.com ([172.16.0.22]) by hqmailsvr01.voltage.com ([172.16.0.22]) with mapi; Sun, 4 May 2008 11:49:30 -0700 From: Luther Martin To: "'Paul Hoffman'" , "ietf-smime@imc.org" Date: Sun, 4 May 2008 11:49:29 -0700 Subject: RE: S/MIME v3.2 IDs key size text (resend, this time not opaque signed with 2k key) Thread-Topic: S/MIME v3.2 IDs key size text (resend, this time not opaque signed with 2k key) Thread-Index: AcitVuoIcgNfTmIRSx+nHgGspK6qxAAvqQKw Message-ID: References: <001801c8ad4e$7c0bc6a0$02b5a8c0@tony> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=4.65.7161:2.4.4,1.2.40,4.0.164 definitions=2008-05-04_05:2008-05-02,2008-05-04,2008-05-04 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=3.1.0-0804140000 definitions=main-0805040108 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: Saturday, May 03, 2008 12:11 PM > To: ietf-smime@imc.org > Subject: RE: S/MIME v3.2 IDs key size text (resend, this time not opaque > signed with 2k key) > Our task is to create a standard that is usable by as many people as > possible while at the same time as setting some minimum operational > security expectations. For interoperability, we need to say "you can > verify signatures created following this spec". For minimum > operational security, we have to pick a size that is reasonable for > the vast majority of users while encouraging software developers to > support all reasonable sizes. > > Please read RFC 3766. If you believe that the numbers in there are > wrong, by all means let the IETF community know. If you believe that > the numbers there are right but you still think that a typical user > needs more than 75 bits of symmetric strength for their signatures, > even though no one has ever done that much effort for even a single > attack in public, please say why. These are interesting points. I believe that the vast majority of users are actually either at government= agencies or financial institutions. The government guys need FIPS 140-2, w= hich is fairly clear about requiring bigger keys (actually the SP that the = IG refers to is), and the FI people need to follow the ANSI X9 recommendati= ons. Both of these require the use of 2K keys Really Soon. Because of this,= I believe that making things reasonable for the vast majority of users mea= ns requiring the support for 2K keys ASAP. I'd also say that what RFC 3766 says is totally irrelevant. The people who = rely on cryptography are the ones that say what an acceptable level of risk= is. In the case of FIs who rely on X9 standards, this means using keys tha= t are fairly big, and may be bigger that RFC 3766 describes. In the case of= government users, this is defined by NIST in SP 800-57. From the point of view of a cryptographer, the key sizes that they require = may seem a bit big, but then the cryptographers aren't the ones dealing wit= h trillions of dollars of risk, either. From peyton7@fujitsu.com Sun May 4 12:34: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 CF8D73A6B78 for ; Sun, 4 May 2008 12:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.761 X-Spam-Level: X-Spam-Status: No, score=-17.761 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, JM_REACTOR_MAILER=1, 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, RCVD_IN_XBL=3.033, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 ur6PedAxSeso for ; Sun, 4 May 2008 12:34:26 -0700 (PDT) Received: from abyb156.neoplus.adsl.tpnet.pl (abyb156.neoplus.adsl.tpnet.pl [83.9.21.156]) by core3.amsl.com (Postfix) with ESMTP id AB21F3A6874 for ; Sun, 4 May 2008 12:34:24 -0700 (PDT) Message-ID: <000701c8ae1d$01846d5b$c3035ea9@ilhpbdib> From: "beltran andre" To: Subject: Video poker and more more games Date: Sun, 04 May 2008 17:47:00 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 World Casino Fair gamming Craps and more more games Free welcome bonus 2400 $ http://worldcasinogates.com/ From owner-ietf-smime@mail.imc.org Mon May 5 13:09: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 5177B3A6D10 for ; Mon, 5 May 2008 13:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 VNyALWSgHmTQ for ; Mon, 5 May 2008 13:08:56 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 9698A3A6AEC for ; Mon, 5 May 2008 13:08: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 m45JqCnq095467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 12:52: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 m45JqCew095466; Mon, 5 May 2008 12:52: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.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m45JqBYD095460 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Mon, 5 May 2008 12:52:11 -0700 (MST) (envelope-from trevorf@exchange.microsoft.com) Received: from df-bhd-01.exchange.corp.microsoft.com (157.54.111.57) by DF-GWY-07.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 5 May 2008 12:52:49 -0700 Received: from df-mlt-02.exchange.corp.microsoft.com (157.54.94.20) by df-bhd-01.exchange.corp.microsoft.com (157.54.111.57) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 5 May 2008 12:52:49 -0700 Received: from DF-MBX-61.exchange.corp.microsoft.com ([169.254.2.227]) by DF-MLT-02.exchange.corp.microsoft.com ([157.54.94.20]) with mapi; Mon, 5 May 2008 12:52:47 -0700 From: Trevor Freeman To: "ietf-smime@imc.org" Date: Mon, 5 May 2008 19:52:08 +0000 Subject: weak authentication issue with rfc5083 Thread-Topic: weak authentication issue with rfc5083 Thread-Index: Aciu6YBkwNV9yBxhQNWEO1d1mLywFg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_F767238E699C2E43895DDFB5F435088F0C2C06204ADFMBX61exchan_" MIME-Version: 1.0 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_000_F767238E699C2E43895DDFB5F435088F0C2C06204ADFMBX61exchan_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have identified a potential for spoofing when using rfc5083. Rfc5083 computes a message HMAC over the content using the authenticated en= cryption algorithms. The message HMAC is calculated based on the content an= d the content encryption key (CEK). A number of allowed key management techniques derive a key encryption key (= KEK) which can be used to authenticate the sender e.g. Static-Static Diffie= Hellman, Kerberos shared secret, shared password. The KEK is used to encry= pt the CEK per recipient. However when the integrity of the message is validated via the message HMAC= , the sender only demonstrates knowledge of the CEK to the recipient. Any other recipient knows the CEK so can construct another message using th= e same CEK and compute the new HMAC and reuse the encrypted KEK data from t= he original message. For example: Alice sends a message to Bob and Mallet. Alice uses different KEK's for b= oth Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using his KEK.= The message decrypts and the HMAC checks out so Bob think the message is f= rom Alice because only Bob and Alice know the KEK. Mallet is the recipient of the original message so he can use his KEK to le= arn the message CEK. Mallet then constructs a new message and encrypts it = using the same CEK as the original message. Mallet copies Bobs KEK recipie= nt Info from Alice's message which contains the same encrypted CEK. Because= Mallet knows the CEK he can also compute the correct HMAC for the new mess= age. Mallet sends the new message to Bob. Bob again uses his KEK to discove= r the CEK and successfully decrypts the message and the HMAC check out so B= ob thinks this new message is also from Alice. This issue only applies when there are multiple recipients. The motivation = to use the new authenticated encryption is to improve performance so soluti= ons like bifurcating messages to use different CEK or signing the message a= re counterproductive. We need an additional structure to allow the sender to demonstrate knowledg= e of both the KEK and CEK per recipient when sending to multiple recipients= . What is the consensus to resolve this? We can version 5083 to document the new structure or we can do document the= new structure via a standalone document. --_000_F767238E699C2E43895DDFB5F435088F0C2C06204ADFMBX61exchan_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have identified a potential for spoofing when using rfc5083.

 

Rfc5083 computes a message HMAC over the content using= the authenticated encryption algorithms. The message HMAC is calculated based on the content = and the content encryption key (CEK).

 

A number of allowed key management techniques derive a= key encryption key (KEK) which can be used to authenticate the sender e.g. Static-Static Diffie Hellman, Kerberos shared secret, shared password. The KEK is used to= encrypt the CEK per recipient.

 

However when the integrity of the message is validated= via the message HMAC, the sender only demonstrates knowledge of the CEK to the recipient.

 

Any other recipient knows the CEK so can construct ano= ther message using the same CEK and compute the new HMAC and reuse the encrypted KEK dat= a from the original message. For example:

 

Alice sends a message to Bob and Mallet. Alice uses  different KEK’s &= nbsp;for both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using  hi= s KEK. The message decrypts and the HMAC checks out so Bob think the message is fr= om Alice because only Bob and Alice know the KEK.

 

Mallet is the recipient of the original message so he can use his KEK to learn the message CEK. Mallet then  constructs a new message and encrypts it usi= ng the same CEK as the original message. Mallet copies Bobs  KEK recipien= t Info from Alice's message which contains the same encrypted CEK. Because Ma= llet knows the CEK he can also compute the correct HMAC for the new message. Mal= let sends the new message to Bob. Bob again uses his KEK to discover the CEK an= d successfully decrypts the message and the HMAC check out so Bob thinks this= new message is also from Alice.

 

This issue only applies when there are multiple recipients. The motivation to us= e the new authenticated encryption is to improve performance so solutions like bi= furcating messages to use different CEK or signing the message are counterproductive.=

 

We need an additional structure to allow the sender to= demonstrate knowledge of both the KEK and CEK per recipient when sending to multiple re= cipients.

What is the consensus to resolve this?

 

We can version 5083 to document the new structure or w= e can do document the new structure via a standalone document.

--_000_F767238E699C2E43895DDFB5F435088F0C2C06204ADFMBX61exchan_-- From owner-ietf-smime@mail.imc.org Mon May 5 13:20:40 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 002FF28C15C for ; Mon, 5 May 2008 13:20:40 -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 9qh3xeAmBloQ for ; Mon, 5 May 2008 13:20:39 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id AE9363A6D44 for ; Mon, 5 May 2008 13:20:38 -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 m45K8g97001999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 13:08:42 -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 m45K8g5m001998; Mon, 5 May 2008 13:08:42 -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 (mail.tor.primus.ca [216.254.136.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m45K8fn9001974; Mon, 5 May 2008 13:08:42 -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 1Jt6zI-0004PL-20; Mon, 05 May 2008 16:08:40 -0400 From: "Tony Capel" To: "'Paul Hoffman'" , "'Turner, Sean P.'" , Subject: RE: S/MIME v3.2 IDs key size text Date: Mon, 5 May 2008 16:08:35 -0400 Message-ID: <003401c8aeeb$ccf3daa0$02b5a8c0@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: AcitjLJkvgon3zgMT46W137Z98cRiQBUq31Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All: I agree that deleting " namely 1024 bits" from the first sentence of the proposed security considerations section paragraph is good. The second = "1024" in the proposed paragraph is not a problem for me since it is not = "normative". With respect to section 4.1 (Key Pair Generation). Is it intended to = change the title of this section? The second paragraph of the current text in 3851bis-01.txt begins "If an S/MIME agent needs to generate ...". So if = the S/MIME agent does NOT need to generate keys (and this is typically the = case, most enrollment & key generation are done externally to messaging = clients) the balance of this paragraph (which mentions the key sizes) is not = normative (as currently drafted - its quite possible that the last sentence of this = paragraph should have been in a separate paragraph). Key generation requirements = are normally (hopefully!) cited in the corresponding CP, where things such = as required key sizes, where they are generated (locally or at the CA), = FIPS-140 Level, etc. should be (!!) explicitly identified. Maybe the second = paragraph of 4.1 could be replaced with a simple statement: "If an S/MIME agent needs to generate one or more key pairs, each SHOULD = be generated according to the corresponding certificate policy, refer for = example to [RFC3647]." The proposed text, and the discussion so far, is really speaking about = "what range of RSA key sizes" needs to be supported. We are NOT providing = security advice, we are just trying to ensure that most smime v3.2 = implementations will interwork in the typical environments expected "in the wild" (and = special environments will be understood by purchasers anyway, so we likely need = not worry about high security applications - only the general "public" environments).=20 A similar issue is already addressed in CERT v3.2 ( draft-ietf-smime-3850bis-01.txt ) in Section 4.3 for certificate = validation. We might consider copying the last sentence of CERT v3.2 Sec 4.3 to the = end of sections 2.2 and 2.3 (just before the Notes): "Key sizes from 1024 bits to 2048 bits MUST be supported."=20 This would also have the advantage of aligning CERT and MSG. Tony | -----Original Message----- | From: owner-ietf-smime@mail.imc.org=20 | [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Paul Hoffman | Sent: May 3, 2008 10:08 PM | To: Turner, Sean P.; ietf-smime@imc.org | Subject: RE: S/MIME v3.2 IDs key size text |=20 |=20 |=20 | At 8:51 PM -0400 5/3/08, Turner, Sean P. wrote: | >I think if we struck ", namely 1024 bits" from the text in=20 | the security=20 | >considerations that it's still a true statement and we won't have to=20 | >change it every time we update the spec. |=20 | I'm OK with that, but I also feel that if we're updating the minimum=20 | mandatory signing length, it is trivial to update the Security=20 | Considerations as well. |=20 From owner-ietf-smime@mail.imc.org Mon May 5 13:34:43 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 4D11B3A6AC1 for ; Mon, 5 May 2008 13:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 8T405lGU0lXa for ; Mon, 5 May 2008 13:34:37 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C2E303A68CE for ; Mon, 5 May 2008 13:34:36 -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 m45KNRLh008142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 13:23:27 -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 m45KNRjP008141; Mon, 5 May 2008 13:23:27 -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 smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m45KNOeW008120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 5 May 2008 13:23:25 -0700 (MST) (envelope-from ietf@augustcellars.com) Received: from GALATIONS (unknown [207.202.179.27]) by smtp3.pacifier.net (Postfix) with ESMTP id F3F6A8D35; Mon, 5 May 2008 13:23:22 -0700 (PDT) From: "Jim Schaad" To: "'Trevor Freeman'" , References: In-Reply-To: Subject: RE: weak authentication issue with rfc5083 Date: Mon, 5 May 2008 13:23:22 -0700 Message-ID: <12c801c8aeed$ddd47670$997d6350$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_12C9_01C8AEB3.31759E70" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aciu6YBkwNV9yBxhQNWEO1d1mLywFgABCUHg Content-Language: en-us Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. ------=_NextPart_000_12C9_01C8AEB3.31759E70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Trevor, The same issue also occurs for AuthenticatedData in RFC 3852. This has been known for a long time. I am not sure how a demonstration of the KEK would solve this issue however. The only way that I know to actually deal with this problem is to place the computed MAC under encryption for each recipient. Jim From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 12:52 PM To: ietf-smime@imc.org Subject: weak authentication issue with rfc5083 We have identified a potential for spoofing when using rfc5083. Rfc5083 computes a message HMAC over the content using the authenticated encryption algorithms. The message HMAC is calculated based on the content and the content encryption key (CEK). A number of allowed key management techniques derive a key encryption key (KEK) which can be used to authenticate the sender e.g. Static-Static Diffie Hellman, Kerberos shared secret, shared password. The KEK is used to encrypt the CEK per recipient. However when the integrity of the message is validated via the message HMAC, the sender only demonstrates knowledge of the CEK to the recipient. Any other recipient knows the CEK so can construct another message using the same CEK and compute the new HMAC and reuse the encrypted KEK data from the original message. For example: Alice sends a message to Bob and Mallet. Alice uses different KEK's for both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using his KEK. The message decrypts and the HMAC checks out so Bob think the message is from Alice because only Bob and Alice know the KEK. Mallet is the recipient of the original message so he can use his KEK to learn the message CEK. Mallet then constructs a new message and encrypts it using the same CEK as the original message. Mallet copies Bobs KEK recipient Info from Alice's message which contains the same encrypted CEK. Because Mallet knows the CEK he can also compute the correct HMAC for the new message. Mallet sends the new message to Bob. Bob again uses his KEK to discover the CEK and successfully decrypts the message and the HMAC check out so Bob thinks this new message is also from Alice. This issue only applies when there are multiple recipients. The motivation to use the new authenticated encryption is to improve performance so solutions like bifurcating messages to use different CEK or signing the message are counterproductive. We need an additional structure to allow the sender to demonstrate knowledge of both the KEK and CEK per recipient when sending to multiple recipients. What is the consensus to resolve this? We can version 5083 to document the new structure or we can do document the new structure via a standalone document. ------=_NextPart_000_12C9_01C8AEB3.31759E70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Trevor,

 

The same issue also = occurs for AuthenticatedData in RFC 3852.  This has been known for a long = time.

 

I am not sure how a demonstration of the KEK would solve this issue however.  The only = way that I know to actually deal with this problem is to place the computed MAC = under encryption for each recipient.

 

Jim

 

 

From:= = owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor = Freeman
Sent: Monday, May 05, 2008 12:52 PM
To: ietf-smime@imc.org
Subject: weak authentication issue with = rfc5083

 

We have identified a potential for spoofing when = using rfc5083.

 

Rfc5083 computes a message HMAC over the content = using the authenticated encryption algorithms. The message HMAC is calculated = based on the content and the content encryption key (CEK).

 

A number of allowed key management techniques = derive a key encryption key (KEK) which can be used to authenticate the sender e.g. Static-Static Diffie Hellman, Kerberos shared secret, shared password. = The KEK is used to encrypt the CEK per recipient.

 

However when the integrity of the message is = validated via the message HMAC, the sender only demonstrates knowledge of the CEK to = the recipient.

 

Any other recipient knows the CEK so can construct = another message using the same CEK and compute the new HMAC and reuse the = encrypted KEK data from the original message. For example:

 

Alice sends a message to Bob and Mallet. Alice uses  different = KEK’s  for both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using  = his KEK. The message decrypts and the HMAC checks out so Bob think the = message is from Alice because only Bob and Alice know the = KEK.

 =

Mallet is the recipient of the original message so he can use his KEK to learn = the message CEK. Mallet then  constructs a new message and encrypts it = using the same CEK as the original message. Mallet copies Bobs  KEK = recipient Info from Alice's message which contains the same encrypted CEK. Because = Mallet knows the CEK he can also compute the correct HMAC for the new message. = Mallet sends the new message to Bob. Bob again uses his KEK to discover the CEK = and successfully decrypts the message and the HMAC check out so Bob thinks = this new message is also from Alice.

 =

This issue only applies when there are multiple recipients. The motivation to = use the new authenticated encryption is to improve performance so solutions = like bifurcating messages to use different CEK or signing the message are counterproductive.

 

We need an additional structure to allow the sender = to demonstrate knowledge of both the KEK and CEK per recipient when sending = to multiple recipients.

What is the consensus to resolve this? =

 

We can version 5083 to document the new structure = or we can do document the new structure via a standalone document.

------=_NextPart_000_12C9_01C8AEB3.31759E70-- From owner-ietf-smime@mail.imc.org Mon May 5 13:53: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 CF6FA3A68AA for ; Mon, 5 May 2008 13:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 jfo8Q5rNsHYG for ; Mon, 5 May 2008 13:53:09 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id DA43328C361 for ; Mon, 5 May 2008 13:51: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 m45Kep54014686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 13:40: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 m45KepPr014685; Mon, 5 May 2008 13:40: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 mail.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.1.17]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m45Ken5B014676 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Mon, 5 May 2008 13:40:50 -0700 (MST) (envelope-from trevorf@exchange.microsoft.com) Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) by DF-GWY-05.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 5 May 2008 13:41:22 -0700 Received: from df-mlt-02.exchange.corp.microsoft.com (157.54.94.20) by df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 5 May 2008 13:41:22 -0700 Received: from DF-MBX-61.exchange.corp.microsoft.com ([169.254.2.227]) by DF-MLT-02.exchange.corp.microsoft.com ([157.54.94.20]) with mapi; Mon, 5 May 2008 13:40:58 -0700 From: Trevor Freeman To: Jim Schaad , "ietf-smime@imc.org" Date: Mon, 5 May 2008 20:40:19 +0000 Subject: RE: weak authentication issue with rfc5083 Thread-Topic: weak authentication issue with rfc5083 Thread-Index: Aciu6YBkwNV9yBxhQNWEO1d1mLywFgABCUHgAAAYJfA= Message-ID: References: <12c801c8aeed$ddd47670$997d6350$@com> In-Reply-To: <12c801c8aeed$ddd47670$997d6350$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_F767238E699C2E43895DDFB5F435088F0C2C06B884DFMBX61exchan_" MIME-Version: 1.0 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_000_F767238E699C2E43895DDFB5F435088F0C2C06B884DFMBX61exchan_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, You can demonstrate knowledge of both HMAC and KEK fairly simply per recipi= ent e.g. by concatenating the KEK with the message HMAC and hashing the res= ult. Since Mallet does not know the KEK they cannot compute the new hash. T= his fix works for both 3852 and 5083. Trevor From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, May 05, 2008 1:23 PM To: Trevor Freeman; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Trevor, The same issue also occurs for AuthenticatedData in RFC 3852. This has bee= n known for a long time. I am not sure how a demonstration of the KEK would solve this issue however= . The only way that I know to actually deal with this problem is to place = the computed MAC under encryption for each recipient. Jim From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 12:52 PM To: ietf-smime@imc.org Subject: weak authentication issue with rfc5083 We have identified a potential for spoofing when using rfc5083. Rfc5083 computes a message HMAC over the content using the authenticated en= cryption algorithms. The message HMAC is calculated based on the content an= d the content encryption key (CEK). A number of allowed key management techniques derive a key encryption key (= KEK) which can be used to authenticate the sender e.g. Static-Static Diffie= Hellman, Kerberos shared secret, shared password. The KEK is used to encry= pt the CEK per recipient. However when the integrity of the message is validated via the message HMAC= , the sender only demonstrates knowledge of the CEK to the recipient. Any other recipient knows the CEK so can construct another message using th= e same CEK and compute the new HMAC and reuse the encrypted KEK data from t= he original message. For example: Alice sends a message to Bob and Mallet. Alice uses different KEK's for b= oth Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using his KEK.= The message decrypts and the HMAC checks out so Bob think the message is f= rom Alice because only Bob and Alice know the KEK. Mallet is the recipient of the original message so he can use his KEK to le= arn the message CEK. Mallet then constructs a new message and encrypts it = using the same CEK as the original message. Mallet copies Bobs KEK recipie= nt Info from Alice's message which contains the same encrypted CEK. Because= Mallet knows the CEK he can also compute the correct HMAC for the new mess= age. Mallet sends the new message to Bob. Bob again uses his KEK to discove= r the CEK and successfully decrypts the message and the HMAC check out so B= ob thinks this new message is also from Alice. This issue only applies when there are multiple recipients. The motivation = to use the new authenticated encryption is to improve performance so soluti= ons like bifurcating messages to use different CEK or signing the message a= re counterproductive. We need an additional structure to allow the sender to demonstrate knowledg= e of both the KEK and CEK per recipient when sending to multiple recipients= . What is the consensus to resolve this? We can version 5083 to document the new structure or we can do document the= new structure via a standalone document. --_000_F767238E699C2E43895DDFB5F435088F0C2C06B884DFMBX61exchan_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim,

You can demonstrate know= ledge of both HMAC and KEK fairly simply per recipient e.g. by concatenating the KEK with the message HMAC and hashing the result. Since Mallet does not know th= e KEK they cannot compute the new hash. This fix works for both 3852 and 5083.

 =

Trevor=

 =

From: Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Monday, May 05, 2008 1:23 PM
To: Trevor Freeman; ietf-smime@imc.org
Subject: RE: weak authentication issue with rfc5083

 

Trevor,

 =

The same issue also occu= rs for AuthenticatedData in RFC 3852.  This has been known for a long time.

 =

I am not sure how a demonstration of the KEK would solve this issue however.  The only way that I know to actually deal with this problem is to place the computed MAC under encryption for each recipient.

 =

Jim

 =

 =

From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 12:52 PM
To: ietf-smime@imc.org
Subject: weak authentication issue with rfc5083

 

We have identified a potential for spoofing when using rfc5083.

 

Rfc5083 computes a message HMAC over the content using= the authenticated encryption algorithms. The message HMAC is calculated based on the content = and the content encryption key (CEK).

 

A number of allowed key management techniques derive a= key encryption key (KEK) which can be used to authenticate the sender e.g. Static-Static Diffie Hellman, Kerberos shared secret, shared password. The = KEK is used to encrypt the CEK per recipient.

 

However when the integrity of the message is validated= via the message HMAC, the sender only demonstrates knowledge of the CEK to the recipient.

 

Any other recipient knows the CEK so can construct ano= ther message using the same CEK and compute the new HMAC and reuse the encrypted= KEK data from the original message. For example:

 

Alice sends a message to Bob and Mallet. Alice uses  different KEK’s  for both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using  his KEK. The message decrypts and the HMAC checks out so Bob th= ink the message is from Alice because only Bob and Alice know the KEK.

 

Mallet is the recipient of the original message so he can use his KEK to learn the message CEK. Mallet then  constructs a new message and encrypts it usi= ng the same CEK as the original message. Mallet copies Bobs  KEK recipien= t Info from Alice's message which contains the same encrypted CEK. Because Ma= llet knows the CEK he can also compute the correct HMAC for the new message. Mal= let sends the new message to Bob. Bob again uses his KEK to discover the CEK an= d successfully decrypts the message and the HMAC check out so Bob thinks this= new message is also from Alice.

 

This issue only applies when there are multiple recipients. The motivation to us= e the new authenticated encryption is to improve performance so solutions lik= e bifurcating messages to use different CEK or signing the message are counterproductive.

 

We need an additional structure to allow the sender to demonstrate knowledge of both the KEK and CEK per recipient when sending to multiple recipients.

What is the consensus to resolve this?

 

We can version 5083 to document the new structure or w= e can do document the new structure via a standalone document.

--_000_F767238E699C2E43895DDFB5F435088F0C2C06B884DFMBX61exchan_-- From owner-ietf-smime@mail.imc.org Mon May 5 14:14: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 496C53A6930 for ; Mon, 5 May 2008 14:14:02 -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 1SOtWfjFJpnA for ; Mon, 5 May 2008 14:14:01 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 0A07E3A68CE for ; Mon, 5 May 2008 14:14: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 m45L22rv022398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 14:02:02 -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 m45L22fX022397; Mon, 5 May 2008 14:02:02 -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 smtp102.biz.mail.re2.yahoo.com (smtp102.biz.mail.re2.yahoo.com [68.142.229.216]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m45L20gA022369 for ; Mon, 5 May 2008 14:02:01 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 24369 invoked from network); 5 May 2008 21:01:51 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.241.4.90 with login) by smtp102.biz.mail.re2.yahoo.com with SMTP; 5 May 2008 21:01:51 -0000 X-YMail-OSG: XKczkFEVM1la1gVI12AR2K8h_abcE9lTgciwaZ6cPOQxTAnV23q.7HIVQ6cCrs_IXocsbO9ykCuVu.QXMmlNVEJiYHRG0vk30oorwW3M._txI3Aw9zmXA21IDxhDbw_7lDA- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "'Tony Capel'" , "'Paul Hoffman'" , References: <003401c8aeeb$ccf3daa0$02b5a8c0@tony> Subject: RE: S/MIME v3.2 IDs key size text Date: Mon, 5 May 2008 16:57:48 -0400 Organization: IECA, Inc. Message-ID: <023701c8aef2$ad31a650$0201a8c0@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.3198 Thread-Index: AcitjLJkvgon3zgMT46W137Z98cRiQBUq31QAASyTyA= In-Reply-To: <003401c8aeeb$ccf3daa0$02b5a8c0@tony> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tony, There was a comment from Paul against the text you cite from 3850bis. He objected to moving the lower bounds from 512 to 1024. I figured I'd post both -02 drafts once we knocked this issue out. spt >-----Original Message----- >From: Tony Capel [mailto:capel@comgate.com] >Sent: Monday, May 05, 2008 4:09 PM >To: 'Paul Hoffman'; 'Turner, Sean P.'; ietf-smime@imc.org >Subject: RE: S/MIME v3.2 IDs key size text > >All: > >I agree that deleting " namely 1024 bits" from the first >sentence of the proposed security considerations section >paragraph is good. The second "1024" >in the proposed paragraph is not a problem for me since it is >not "normative". > >With respect to section 4.1 (Key Pair Generation). Is it >intended to change the title of this section? The second >paragraph of the current text in 3851bis-01.txt begins "If an >S/MIME agent needs to generate ...". So if the S/MIME agent >does NOT need to generate keys (and this is typically the >case, most enrollment & key generation are done externally to >messaging clients) the balance of this paragraph (which >mentions the key sizes) is not normative (as currently drafted >- its quite possible that the last sentence of this paragraph >should have been in a separate paragraph). Key generation >requirements are normally (hopefully!) cited in the >corresponding CP, where things such as required key sizes, >where they are generated (locally or at the CA), FIPS-140 >Level, etc. should be (!!) explicitly identified. Maybe the >second paragraph of >4.1 could be replaced with a simple statement: > >"If an S/MIME agent needs to generate one or more key pairs, >each SHOULD be generated according to the corresponding >certificate policy, refer for example to [RFC3647]." > >The proposed text, and the discussion so far, is really >speaking about "what range of RSA key sizes" needs to be >supported. We are NOT providing security advice, we are just >trying to ensure that most smime v3.2 implementations will >interwork in the typical environments expected "in the wild" >(and special environments will be understood by purchasers >anyway, so we likely need not worry about high security >applications - only the general "public" >environments). > >A similar issue is already addressed in CERT v3.2 ( >draft-ietf-smime-3850bis-01.txt ) in Section 4.3 for >certificate validation. >We might consider copying the last sentence of CERT v3.2 Sec >4.3 to the end of sections 2.2 and 2.3 (just before the Notes): > > "Key sizes from 1024 bits to 2048 bits MUST be supported." > >This would also have the advantage of aligning CERT and MSG. > >Tony > > >| -----Original Message----- >| From: owner-ietf-smime@mail.imc.org >| [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Paul Hoffman >| Sent: May 3, 2008 10:08 PM >| To: Turner, Sean P.; ietf-smime@imc.org >| Subject: RE: S/MIME v3.2 IDs key size text >| >| >| >| At 8:51 PM -0400 5/3/08, Turner, Sean P. wrote: >| >I think if we struck ", namely 1024 bits" from the text in >| the security >| >considerations that it's still a true statement and we >won't have to >| >change it every time we update the spec. >| >| I'm OK with that, but I also feel that if we're updating the minimum >| mandatory signing length, it is trivial to update the Security >| Considerations as well. >| > From owner-ietf-smime@mail.imc.org Mon May 5 14:14: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 694B73A693F for ; Mon, 5 May 2008 14:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Wp64fA2ETO86 for ; Mon, 5 May 2008 14:14:06 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id BF6513A67D2 for ; Mon, 5 May 2008 14:14:05 -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 m45L3YQ9023146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 14:03:34 -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 m45L3YgZ023144; Mon, 5 May 2008 14:03:34 -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.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m45L3V00023118 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Mon, 5 May 2008 14:03:33 -0700 (MST) (envelope-from trevorf@exchange.microsoft.com) Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) by DF-GWY-07.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 5 May 2008 14:04:10 -0700 Received: from df-mlt-02.exchange.corp.microsoft.com (157.54.94.20) by df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 5 May 2008 14:04:10 -0700 Received: from DF-MBX-61.exchange.corp.microsoft.com ([169.254.2.227]) by DF-MLT-02.exchange.corp.microsoft.com ([157.54.94.20]) with mapi; Mon, 5 May 2008 14:04:02 -0700 From: Trevor Freeman To: Trevor Freeman , Jim Schaad , "ietf-smime@imc.org" Date: Mon, 5 May 2008 21:03:23 +0000 Subject: RE: weak authentication issue with rfc5083 Thread-Topic: weak authentication issue with rfc5083 Thread-Index: Aciu6YBkwNV9yBxhQNWEO1d1mLywFgABCUHgAAAYJfAAAU9AUA== Message-ID: References: <12c801c8aeed$ddd47670$997d6350$@com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_F767238E699C2E43895DDFB5F435088F0C2C06CFE4DFMBX61exchan_" MIME-Version: 1.0 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_000_F767238E699C2E43895DDFB5F435088F0C2C06CFE4DFMBX61exchan_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Another suggestion is to use the kek to wrap the hmac just like you wrapped= the CEK. From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 1:40 PM To: Jim Schaad; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Hi Jim, You can demonstrate knowledge of both HMAC and KEK fairly simply per recipi= ent e.g. by concatenating the KEK with the message HMAC and hashing the res= ult. Since Mallet does not know the KEK they cannot compute the new hash. T= his fix works for both 3852 and 5083. Trevor From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, May 05, 2008 1:23 PM To: Trevor Freeman; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Trevor, The same issue also occurs for AuthenticatedData in RFC 3852. This has bee= n known for a long time. I am not sure how a demonstration of the KEK would solve this issue however= . The only way that I know to actually deal with this problem is to place = the computed MAC under encryption for each recipient. Jim From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 12:52 PM To: ietf-smime@imc.org Subject: weak authentication issue with rfc5083 We have identified a potential for spoofing when using rfc5083. Rfc5083 computes a message HMAC over the content using the authenticated en= cryption algorithms. The message HMAC is calculated based on the content an= d the content encryption key (CEK). A number of allowed key management techniques derive a key encryption key (= KEK) which can be used to authenticate the sender e.g. Static-Static Diffie= Hellman, Kerberos shared secret, shared password. The KEK is used to encry= pt the CEK per recipient. However when the integrity of the message is validated via the message HMAC= , the sender only demonstrates knowledge of the CEK to the recipient. Any other recipient knows the CEK so can construct another message using th= e same CEK and compute the new HMAC and reuse the encrypted KEK data from t= he original message. For example: Alice sends a message to Bob and Mallet. Alice uses different KEK's for b= oth Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using his KEK.= The message decrypts and the HMAC checks out so Bob think the message is f= rom Alice because only Bob and Alice know the KEK. Mallet is the recipient of the original message so he can use his KEK to le= arn the message CEK. Mallet then constructs a new message and encrypts it = using the same CEK as the original message. Mallet copies Bobs KEK recipie= nt Info from Alice's message which contains the same encrypted CEK. Because= Mallet knows the CEK he can also compute the correct HMAC for the new mess= age. Mallet sends the new message to Bob. Bob again uses his KEK to discove= r the CEK and successfully decrypts the message and the HMAC check out so B= ob thinks this new message is also from Alice. This issue only applies when there are multiple recipients. The motivation = to use the new authenticated encryption is to improve performance so soluti= ons like bifurcating messages to use different CEK or signing the message a= re counterproductive. We need an additional structure to allow the sender to demonstrate knowledg= e of both the KEK and CEK per recipient when sending to multiple recipients= . What is the consensus to resolve this? We can version 5083 to document the new structure or we can do document the= new structure via a standalone document. --_000_F767238E699C2E43895DDFB5F435088F0C2C06CFE4DFMBX61exchan_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Another suggestion is to= use the kek to wrap the hmac just like you wrapped the CEK.

 =

From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 1:40 PM
To: Jim Schaad; ietf-smime@imc.org
Subject: RE: weak authentication issue with rfc5083

 

Hi Jim,

You can demonstrate know= ledge of both HMAC and KEK fairly simply per recipient e.g. by concatenating the KEK with the message HMAC and hashing the result. Since Mallet does not know th= e KEK they cannot compute the new hash. This fix works for both 3852 and 5083= .

 =

Trevor=

 =

From: Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Monday, May 05, 2008 1:23 PM
To: Trevor Freeman; ietf-smime@imc.org
Subject: RE: weak authentication issue with rfc5083

 

Trevor,

 =

The same issue also occu= rs for AuthenticatedData in RFC 3852.  This has been known for a long time.

 =

I am not sure how a demonstration of the KEK would solve this issue however.  The only way that I know to actually deal with this problem is to place the computed MAC under encryption for each recipient.

 =

Jim

 =

 =

From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 12:52 PM
To: ietf-smime@imc.org
Subject: weak authentication issue with rfc5083

 

We have identified a potential for spoofing when using rfc5083.

 

Rfc5083 computes a message HMAC over the content using= the authenticated encryption algorithms. The message HMAC is calculated based o= n the content and the content encryption key (CEK).

 

A number of allowed key management techniques derive a= key encryption key (KEK) which can be used to authenticate the sender e.g. Static-Static Diffie Hellman, Kerberos shared secret, shared password. The = KEK is used to encrypt the CEK per recipient.

 

However when the integrity of the message is validated= via the message HMAC, the sender only demonstrates knowledge of the CEK to the recipient.

 

Any other recipient knows the CEK so can construct ano= ther message using the same CEK and compute the new HMAC and reuse the encrypted= KEK data from the original message. For example:

 

Alice sends a message to Bob and Mallet. Alice uses  different KEK’s  for both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using  his KEK. The message decrypts and the HMAC checks out so Bob th= ink the message is from Alice because only Bob and Alice know the KEK.

 

Mallet is the recipient of the original message so he can use his KEK to learn the message CEK. Mallet then  constructs a new message and encrypts it usi= ng the same CEK as the original message. Mallet copies Bobs  KEK recipien= t Info from Alice's message which contains the same encrypted CEK. Because Ma= llet knows the CEK he can also compute the correct HMAC for the new message. Mal= let sends the new message to Bob. Bob again uses his KEK to discover the CEK an= d successfully decrypts the message and the HMAC check out so Bob thinks this= new message is also from Alice.

 

This issue only applies when there are multiple recipients. The motivation to us= e the new authenticated encryption is to improve performance so solutions lik= e bifurcating messages to use different CEK or signing the message are counterproductive.

 

We need an additional structure to allow the sender to demonstrate knowledge of both the KEK and CEK per recipient when sending to multiple recipients.

What is the consensus to resolve this?

 

We can version 5083 to document the new structure or w= e can do document the new structure via a standalone document.

--_000_F767238E699C2E43895DDFB5F435088F0C2C06CFE4DFMBX61exchan_-- From owner-ietf-smime@mail.imc.org Mon May 5 14:46: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 2D9C63A6B94 for ; Mon, 5 May 2008 14:46:48 -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 dM3nW53aH27X for ; Mon, 5 May 2008 14:46:47 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 867A23A68DC for ; Mon, 5 May 2008 14:46:46 -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 m45LY95g035409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 14:34:09 -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 m45LY9FG035408; Mon, 5 May 2008 14:34:09 -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-05.primus.ca (mail.tor.primus.ca [216.254.136.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m45LY8B1035378; Mon, 5 May 2008 14:34:08 -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-05.primus.ca with esmtps (TLSv1:RC4-MD5:128) (Exim 4.63) (envelope-from ) id 1Jt8Io-0007mq-2E; Mon, 05 May 2008 17:32:55 -0400 From: "Tony Capel" To: "'Turner, Sean P.'" , "'Paul Hoffman'" , Subject: RE: S/MIME v3.2 IDs key size text Date: Mon, 5 May 2008 17:34:02 -0400 Message-ID: <004301c8aef7$bcafeba0$02b5a8c0@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: <023701c8aef2$ad31a650$0201a8c0@Wylie> Importance: Normal Thread-Index: AcitjLJkvgon3zgMT46W137Z98cRiQBUq31QAASyTyAAAQJGwA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sean: Agreed, the text in 3850bis and 3851bis needs to align. I have no = problems with support for smaller key sizes. I expect constraints on key size to be implemented by the certificate = issuer anyway. If you get a 512 key in a cert you trust you must be able to = use it, no? =20 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: May 5, 2008 4:58 PM | To: 'Tony Capel'; 'Paul Hoffman'; ietf-smime@imc.org | Subject: RE: S/MIME v3.2 IDs key size text |=20 |=20 |=20 | Tony, |=20 | There was a comment from Paul against the text you cite from=20 | 3850bis. He objected to moving the lower bounds from 512 to=20 | 1024. I figured I'd post both -02 drafts once we knocked this=20 | issue out. |=20 | spt |=20 | >-----Original Message----- | >From: Tony Capel [mailto:capel@comgate.com] | >Sent: Monday, May 05, 2008 4:09 PM | >To: 'Paul Hoffman'; 'Turner, Sean P.'; ietf-smime@imc.org | >Subject: RE: S/MIME v3.2 IDs key size text | > | >All: | > | >I agree that deleting " namely 1024 bits" from the first | >sentence of the proposed security considerations section=20 | >paragraph is good. The second "1024" | >in the proposed paragraph is not a problem for me since it is=20 | >not "normative". | > | >With respect to section 4.1 (Key Pair Generation). Is it | >intended to change the title of this section? The second=20 | >paragraph of the current text in 3851bis-01.txt begins "If an=20 | >S/MIME agent needs to generate ...". So if the S/MIME agent=20 | >does NOT need to generate keys (and this is typically the=20 | >case, most enrollment & key generation are done externally to=20 | >messaging clients) the balance of this paragraph (which=20 | >mentions the key sizes) is not normative (as currently drafted=20 | >- its quite possible that the last sentence of this paragraph=20 | >should have been in a separate paragraph). Key generation=20 | >requirements are normally (hopefully!) cited in the=20 | >corresponding CP, where things such as required key sizes,=20 | >where they are generated (locally or at the CA), FIPS-140=20 | >Level, etc. should be (!!) explicitly identified. Maybe the=20 | >second paragraph of | >4.1 could be replaced with a simple statement: | > | >"If an S/MIME agent needs to generate one or more key pairs, | >each SHOULD be generated according to the corresponding=20 | >certificate policy, refer for example to [RFC3647]." | > | >The proposed text, and the discussion so far, is really | >speaking about "what range of RSA key sizes" needs to be=20 | >supported. We are NOT providing security advice, we are just=20 | >trying to ensure that most smime v3.2 implementations will=20 | >interwork in the typical environments expected "in the wild"=20 | >(and special environments will be understood by purchasers=20 | >anyway, so we likely need not worry about high security=20 | >applications - only the general "public" | >environments).=20 | > | >A similar issue is already addressed in CERT v3.2 ( | >draft-ietf-smime-3850bis-01.txt ) in Section 4.3 for=20 | >certificate validation. | >We might consider copying the last sentence of CERT v3.2 Sec=20 | >4.3 to the end of sections 2.2 and 2.3 (just before the Notes): | > | > "Key sizes from 1024 bits to 2048 bits MUST be supported." | > | >This would also have the advantage of aligning CERT and MSG. | > | >Tony | > | > | >| -----Original Message----- | >| From: owner-ietf-smime@mail.imc.org=20 | >| [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Paul Hoffman | >| Sent: May 3, 2008 10:08 PM | >| To: Turner, Sean P.; ietf-smime@imc.org | >| Subject: RE: S/MIME v3.2 IDs key size text | >|=20 | >|=20 | >|=20 | >| At 8:51 PM -0400 5/3/08, Turner, Sean P. wrote: | >| >I think if we struck ", namely 1024 bits" from the text in | >| the security | >| >considerations that it's still a true statement and we | >won't have to | >| >change it every time we update the spec. | >|=20 | >| I'm OK with that, but I also feel that if we're updating=20 | the minimum | >| mandatory signing length, it is trivial to update the Security=20 | >| Considerations as well. | >|=20 | > |=20 From owner-ietf-smime@mail.imc.org Mon May 5 15:27: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 352203A68F6 for ; Mon, 5 May 2008 15:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 QUnMQnUZLsEr for ; Mon, 5 May 2008 15:27:49 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 5291728C234 for ; Mon, 5 May 2008 15:27:48 -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 m45MAYw3051378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 15:10:34 -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 m45MAYA3051377; Mon, 5 May 2008 15:10:34 -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 cx295.800onemail.com (cx295.800onemail.com [209.171.54.152]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m45MAUo6051310 for ; Mon, 5 May 2008 15:10:33 -0700 (MST) (envelope-from dbrown@certicom.com) Received: from ex13-n02.exchserver.com ([192.168.162.157]) by cx295.800onemail.com (8.13.1/8.13.1) with ESMTP id m45M9Ueo016303; Mon, 5 May 2008 18:09:31 -0400 Received: from EX40.exchserver.com ([192.168.162.205]) by ex13-n02.exchserver.com ([192.168.162.161]) with mapi; Mon, 5 May 2008 18:06:34 -0400 From: Daniel Brown To: Trevor Freeman CC: "ietf-smime@imc.org" Date: Mon, 5 May 2008 18:09:29 -0400 Subject: RE: weak authentication issue with rfc5083 Thread-Topic: weak authentication issue with rfc5083 Thread-Index: Aciu6YBkwNV9yBxhQNWEO1d1mLywFgAETq5Q Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C49217E2D694874EB820EA90DCE67619C22761EEEX40exchserverc_" MIME-Version: 1.0 X-CRXEFW-Info: Please contact Ceryx for more information X-CRXEFW-Virus: Clean X-CRXEFW-From: dbrown@certicom.com Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_000_C49217E2D694874EB820EA90DCE67619C22761EEEX40exchserverc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Trevor, Essentially the same problem was commented upon in RFC 3278: http://tools.ietf.org/html/rfc3278#section-4.1.2 but no solution was provided other than to use separate AuthenticatedData p= er recipient. There are some other possible solutions, however. For example, in the case of Diffie-Hellman, the input into the KDF used to = compute the KEK from the raw DH secret can be include the MAC tag, which pr= events message substitution. See Section 5 of http://eprint.iacr.org/2005/= 056 for more discussion. Best regards, Dan From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 3:52 PM To: ietf-smime@imc.org Subject: weak authentication issue with rfc5083 We have identified a potential for spoofing when using rfc5083. Rfc5083 computes a message HMAC over the content using the authenticated en= cryption algorithms. The message HMAC is calculated based on the content an= d the content encryption key (CEK). A number of allowed key management techniques derive a key encryption key (= KEK) which can be used to authenticate the sender e.g. Static-Static Diffie= Hellman, Kerberos shared secret, shared password. The KEK is used to encry= pt the CEK per recipient. However when the integrity of the message is validated via the message HMAC= , the sender only demonstrates knowledge of the CEK to the recipient. Any other recipient knows the CEK so can construct another message using th= e same CEK and compute the new HMAC and reuse the encrypted KEK data from t= he original message. For example: Alice sends a message to Bob and Mallet. Alice uses different KEK's for b= oth Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using his KEK.= The message decrypts and the HMAC checks out so Bob think the message is f= rom Alice because only Bob and Alice know the KEK. Mallet is the recipient of the original message so he can use his KEK to le= arn the message CEK. Mallet then constructs a new message and encrypts it = using the same CEK as the original message. Mallet copies Bobs KEK recipie= nt Info from Alice's message which contains the same encrypted CEK. Because= Mallet knows the CEK he can also compute the correct HMAC for the new mess= age. Mallet sends the new message to Bob. Bob again uses his KEK to discove= r the CEK and successfully decrypts the message and the HMAC check out so B= ob thinks this new message is also from Alice. This issue only applies when there are multiple recipients. The motivation = to use the new authenticated encryption is to improve performance so soluti= ons like bifurcating messages to use different CEK or signing the message a= re counterproductive. We need an additional structure to allow the sender to demonstrate knowledg= e of both the KEK and CEK per recipient when sending to multiple recipients= . What is the consensus to resolve this? We can version 5083 to document the new structure or we can do document the= new structure via a standalone document. --_000_C49217E2D694874EB820EA90DCE67619C22761EEEX40exchserverc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Trevor,

 =

Essentially the same pro= blem was commented upon in RFC 3278:

 =

http://tools.ietf= .org/html/rfc3278#section-4.1.2

 =

but no solution was prov= ided other than to use separate AuthenticatedData per recipient. There are some other = possible solutions, however. 

 =

For example, in the case= of Diffie-Hellman, the input into the KDF used to compute the KEK from the raw= DH secret can be include the MAC tag, which prevents message substitution.&nbs= p; See Section 5 of http://eprint.= iacr.org/2005/056 for more discussion.

 =

Best regards,=

 =

    =             Dan=

 =

From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 3:52 PM
To: ietf-smime@imc.org
Subject: weak authentication issue with rfc5083

 

We have identified a potential for spoofing when using rfc5083.

 

Rfc5083 computes a message HMAC over the content using= the authenticated encryption algorithms. The message HMAC is calculated based o= n the content and the content encryption key (CEK).

 

A number of allowed key management techniques derive a= key encryption key (KEK) which can be used to authenticate the sender e.g. Static-Static Diffie Hellman, Kerberos shared secret, shared password. The = KEK is used to encrypt the CEK per recipient.

 

However when the integrity of the message is validated= via the message HMAC, the sender only demonstrates knowledge of the CEK to the recipient.

 

Any other recipient knows the CEK so can construct ano= ther message using the same CEK and compute the new HMAC and reuse the encrypted= KEK data from the original message. For example:

 

Alice sends a message to Bob and Mallet. Alice uses  different KEK’s  for both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using  his KEK. The message decrypts and the HMAC checks out so Bob th= ink the message is from Alice because only Bob and Alice know the KEK.

 

Mallet is the recipient of the original message so he can use his KEK to learn the message CEK. Mallet then  constructs a new message and encrypts it usi= ng the same CEK as the original message. Mallet copies Bobs  KEK recipien= t Info from Alice's message which contains the same encrypted CEK. Because Ma= llet knows the CEK he can also compute the correct HMAC for the new message. Mal= let sends the new message to Bob. Bob again uses his KEK to discover the CEK an= d successfully decrypts the message and the HMAC check out so Bob thinks this= new message is also from Alice.

 

This issue only applies when there are multiple recipients. The motivation to us= e the new authenticated encryption is to improve performance so solutions lik= e bifurcating messages to use different CEK or signing the message are counterproductive.

 

We need an additional structure to allow the sender to demonstrate knowledge of both the KEK and CEK per recipient when sending to multiple recipients.

What is the consensus to resolve this?

 

We can version 5083 to document the new structure or w= e can do document the new structure via a standalone document.

--_000_C49217E2D694874EB820EA90DCE67619C22761EEEX40exchserverc_-- From owner-ietf-smime@mail.imc.org Mon May 5 15:50:24 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 7BC313A69F8 for ; Mon, 5 May 2008 15:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 vKVh5PLBqu3H for ; Mon, 5 May 2008 15:50:17 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 7A8533A6944 for ; Mon, 5 May 2008 15:50:16 -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 m45McNq0064653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 15:38:24 -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 m45McNhF064652; Mon, 5 May 2008 15:38: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 smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m45McMwp064644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 5 May 2008 15:38:23 -0700 (MST) (envelope-from ietf@augustcellars.com) Received: from GALATIONS (unknown [207.202.179.27]) by smtp3.pacifier.net (Postfix) with ESMTP id 76D9585A1; Mon, 5 May 2008 15:38:15 -0700 (PDT) From: "Jim Schaad" To: "'Trevor Freeman'" , References: <12c801c8aeed$ddd47670$997d6350$@com> In-Reply-To: Subject: RE: weak authentication issue with rfc5083 Date: Mon, 5 May 2008 15:38:14 -0700 Message-ID: <130901c8af00$b698b0e0$23ca12a0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_130A_01C8AEC6.0A39D8E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aciu6YBkwNV9yBxhQNWEO1d1mLywFgABCUHgAAAYJfAAAU9AUAADVTBQ Content-Language: en-us Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. ------=_NextPart_000_130A_01C8AEC6.0A39D8E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The downside of this would be that you could no longer do one pass encoding. You would need to compute the HMAC prior to computing the recipient infos. Jim From: Trevor Freeman [mailto:trevorf@exchange.microsoft.com] Sent: Monday, May 05, 2008 2:03 PM To: Trevor Freeman; Jim Schaad; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Another suggestion is to use the kek to wrap the hmac just like you wrapped the CEK. From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 1:40 PM To: Jim Schaad; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Hi Jim, You can demonstrate knowledge of both HMAC and KEK fairly simply per recipient e.g. by concatenating the KEK with the message HMAC and hashing the result. Since Mallet does not know the KEK they cannot compute the new hash. This fix works for both 3852 and 5083. Trevor From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, May 05, 2008 1:23 PM To: Trevor Freeman; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Trevor, The same issue also occurs for AuthenticatedData in RFC 3852. This has been known for a long time. I am not sure how a demonstration of the KEK would solve this issue however. The only way that I know to actually deal with this problem is to place the computed MAC under encryption for each recipient. Jim From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 12:52 PM To: ietf-smime@imc.org Subject: weak authentication issue with rfc5083 We have identified a potential for spoofing when using rfc5083. Rfc5083 computes a message HMAC over the content using the authenticated encryption algorithms. The message HMAC is calculated based on the content and the content encryption key (CEK). A number of allowed key management techniques derive a key encryption key (KEK) which can be used to authenticate the sender e.g. Static-Static Diffie Hellman, Kerberos shared secret, shared password. The KEK is used to encrypt the CEK per recipient. However when the integrity of the message is validated via the message HMAC, the sender only demonstrates knowledge of the CEK to the recipient. Any other recipient knows the CEK so can construct another message using the same CEK and compute the new HMAC and reuse the encrypted KEK data from the original message. For example: Alice sends a message to Bob and Mallet. Alice uses different KEK's for both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using his KEK. The message decrypts and the HMAC checks out so Bob think the message is from Alice because only Bob and Alice know the KEK. Mallet is the recipient of the original message so he can use his KEK to learn the message CEK. Mallet then constructs a new message and encrypts it using the same CEK as the original message. Mallet copies Bobs KEK recipient Info from Alice's message which contains the same encrypted CEK. Because Mallet knows the CEK he can also compute the correct HMAC for the new message. Mallet sends the new message to Bob. Bob again uses his KEK to discover the CEK and successfully decrypts the message and the HMAC check out so Bob thinks this new message is also from Alice. This issue only applies when there are multiple recipients. The motivation to use the new authenticated encryption is to improve performance so solutions like bifurcating messages to use different CEK or signing the message are counterproductive. We need an additional structure to allow the sender to demonstrate knowledge of both the KEK and CEK per recipient when sending to multiple recipients. What is the consensus to resolve this? We can version 5083 to document the new structure or we can do document the new structure via a standalone document. ------=_NextPart_000_130A_01C8AEC6.0A39D8E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The downside of this = would be that you could no longer do one pass encoding.  You would need to = compute the HMAC prior to computing the recipient infos.

 

Jim

 

 

From:= Trevor = Freeman [mailto:trevorf@exchange.microsoft.com]
Sent: Monday, May 05, 2008 2:03 PM
To: Trevor Freeman; Jim Schaad; ietf-smime@imc.org
Subject: RE: weak authentication issue with = rfc5083

 

Another suggestion is = to use the kek to wrap the hmac just like you wrapped the = CEK.

 

From:= owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 1:40 PM
To: Jim Schaad; ietf-smime@imc.org
Subject: RE: weak authentication issue with = rfc5083

 

Hi = Jim,

You can demonstrate = knowledge of both HMAC and KEK fairly simply per recipient e.g. by concatenating the = KEK with the message HMAC and hashing the result. Since Mallet does not know = the KEK they cannot compute the new hash. This fix works for both 3852 and = 5083.

 

Trevor

 

From:= Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Monday, May 05, 2008 1:23 PM
To: Trevor Freeman; ietf-smime@imc.org
Subject: RE: weak authentication issue with = rfc5083

 

Trevor,

 

The same issue also = occurs for AuthenticatedData in RFC 3852.  This has been known for a long = time.

 

I am not sure how a demonstration of the KEK would solve this issue however.  The only = way that I know to actually deal with this problem is to place the computed = MAC under encryption for each recipient.

 

Jim

 

 

From:= owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 12:52 PM
To: ietf-smime@imc.org
Subject: weak authentication issue with = rfc5083

 

We have identified a potential for spoofing when = using rfc5083.

 

Rfc5083 computes a message HMAC over the content = using the authenticated encryption algorithms. The message HMAC is calculated = based on the content and the content encryption key (CEK).

 

A number of allowed key management techniques = derive a key encryption key (KEK) which can be used to authenticate the sender e.g. Static-Static Diffie Hellman, Kerberos shared secret, shared password. = The KEK is used to encrypt the CEK per recipient.

 

However when the integrity of the message is = validated via the message HMAC, the sender only demonstrates knowledge of the CEK to = the recipient.

 

Any other recipient knows the CEK so can construct = another message using the same CEK and compute the new HMAC and reuse the = encrypted KEK data from the original message. For example:

 

Alice sends a message to Bob and Mallet. Alice uses  different = KEK’s  for both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using  = his KEK. The message decrypts and the HMAC checks out so Bob think the = message is from Alice because only Bob and Alice know the = KEK.

 =

Mallet is the recipient of the original message so he can use his KEK to learn = the message CEK. Mallet then  constructs a new message and encrypts it = using the same CEK as the original message. Mallet copies Bobs  KEK recipient = Info from Alice's message which contains the same encrypted CEK. Because = Mallet knows the CEK he can also compute the correct HMAC for the new message. = Mallet sends the new message to Bob. Bob again uses his KEK to discover the CEK = and successfully decrypts the message and the HMAC check out so Bob thinks = this new message is also from Alice.

 =

This issue only applies when there are multiple recipients. The motivation to = use the new authenticated encryption is to improve performance so solutions = like bifurcating messages to use different CEK or signing the message are counterproductive.

 

We need an additional structure to allow the sender = to demonstrate knowledge of both the KEK and CEK per recipient when sending = to multiple recipients.

What is the consensus to resolve this? =

 

We can version 5083 to document the new structure = or we can do document the new structure via a standalone document.

------=_NextPart_000_130A_01C8AEC6.0A39D8E0-- From owner-ietf-smime@mail.imc.org Mon May 5 15:51: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 0E74A3A6870 for ; Mon, 5 May 2008 15:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 3IQ3Y38DSndY for ; Mon, 5 May 2008 15:51:51 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 8AC5428C372 for ; Mon, 5 May 2008 15:51:24 -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 m45MfZZn066012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 15:41:35 -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 m45MfZna066011; Mon, 5 May 2008 15:41:35 -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.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.1.17]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m45MfXfm065996 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Mon, 5 May 2008 15:41:34 -0700 (MST) (envelope-from trevorf@exchange.microsoft.com) Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) by DF-GWY-05.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 5 May 2008 15:42:12 -0700 Received: from df-mlt-02.exchange.corp.microsoft.com (157.54.94.20) by df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 5 May 2008 15:42:12 -0700 Received: from DF-MBX-61.exchange.corp.microsoft.com ([169.254.2.227]) by DF-MLT-02.exchange.corp.microsoft.com ([157.54.94.20]) with mapi; Mon, 5 May 2008 15:42:10 -0700 From: Trevor Freeman To: Jim Schaad , "ietf-smime@imc.org" Date: Mon, 5 May 2008 22:41:31 +0000 Subject: RE: weak authentication issue with rfc5083 Thread-Topic: weak authentication issue with rfc5083 Thread-Index: Aciu6YBkwNV9yBxhQNWEO1d1mLywFgABCUHgAAAYJfAAAU9AUAADVTBQAAAPh/A= Message-ID: References: <12c801c8aeed$ddd47670$997d6350$@com> <130901c8af00$b698b0e0$23ca12a0$@com> In-Reply-To: <130901c8af00$b698b0e0$23ca12a0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_F767238E699C2E43895DDFB5F435088F0C2C07BE77DFMBX61exchan_" MIME-Version: 1.0 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_000_F767238E699C2E43895DDFB5F435088F0C2C07BE77DFMBX61exchan_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Not if you send the recipient info's with the encrypted hmac as an unauthen= ticated attribute. Trevor From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, May 05, 2008 3:38 PM To: Trevor Freeman; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 The downside of this would be that you could no longer do one pass encoding= . You would need to compute the HMAC prior to computing the recipient info= s. Jim From: Trevor Freeman [mailto:trevorf@exchange.microsoft.com] Sent: Monday, May 05, 2008 2:03 PM To: Trevor Freeman; Jim Schaad; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Another suggestion is to use the kek to wrap the hmac just like you wrapped= the CEK. From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 1:40 PM To: Jim Schaad; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Hi Jim, You can demonstrate knowledge of both HMAC and KEK fairly simply per recipi= ent e.g. by concatenating the KEK with the message HMAC and hashing the res= ult. Since Mallet does not know the KEK they cannot compute the new hash. T= his fix works for both 3852 and 5083. Trevor From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, May 05, 2008 1:23 PM To: Trevor Freeman; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Trevor, The same issue also occurs for AuthenticatedData in RFC 3852. This has bee= n known for a long time. I am not sure how a demonstration of the KEK would solve this issue however= . The only way that I know to actually deal with this problem is to place = the computed MAC under encryption for each recipient. Jim From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 12:52 PM To: ietf-smime@imc.org Subject: weak authentication issue with rfc5083 We have identified a potential for spoofing when using rfc5083. Rfc5083 computes a message HMAC over the content using the authenticated en= cryption algorithms. The message HMAC is calculated based on the content an= d the content encryption key (CEK). A number of allowed key management techniques derive a key encryption key (= KEK) which can be used to authenticate the sender e.g. Static-Static Diffie= Hellman, Kerberos shared secret, shared password. The KEK is used to encry= pt the CEK per recipient. However when the integrity of the message is validated via the message HMAC= , the sender only demonstrates knowledge of the CEK to the recipient. Any other recipient knows the CEK so can construct another message using th= e same CEK and compute the new HMAC and reuse the encrypted KEK data from t= he original message. For example: Alice sends a message to Bob and Mallet. Alice uses different KEK's for b= oth Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using his KEK.= The message decrypts and the HMAC checks out so Bob think the message is f= rom Alice because only Bob and Alice know the KEK. Mallet is the recipient of the original message so he can use his KEK to le= arn the message CEK. Mallet then constructs a new message and encrypts it = using the same CEK as the original message. Mallet copies Bobs KEK recipie= nt Info from Alice's message which contains the same encrypted CEK. Because= Mallet knows the CEK he can also compute the correct HMAC for the new mess= age. Mallet sends the new message to Bob. Bob again uses his KEK to discove= r the CEK and successfully decrypts the message and the HMAC check out so B= ob thinks this new message is also from Alice. This issue only applies when there are multiple recipients. The motivation = to use the new authenticated encryption is to improve performance so soluti= ons like bifurcating messages to use different CEK or signing the message a= re counterproductive. We need an additional structure to allow the sender to demonstrate knowledg= e of both the KEK and CEK per recipient when sending to multiple recipients= . What is the consensus to resolve this? We can version 5083 to document the new structure or we can do document the= new structure via a standalone document. --_000_F767238E699C2E43895DDFB5F435088F0C2C07BE77DFMBX61exchan_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Not if you send the reci= pient info’s with the encrypted hmac as an unauthenticated attribute.<= /p>

 =

Trevor=

 =

From: Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Monday, May 05, 2008 3:38 PM
To: Trevor Freeman; ietf-smime@imc.org
Subject: RE: weak authentication issue with rfc5083

 

The downside of this wou= ld be that you could no longer do one pass encoding.  You would need to comp= ute the HMAC prior to computing the recipient infos.

 =

Jim

 =

 =

From: Trevor Freema= n [mailto:trevorf@exchange.microsoft.com]
Sent: Monday, May 05, 2008 2:03 PM
To: Trevor Freeman; Jim Schaad; ietf-smime@imc.org
Subject: RE: weak authentication issue with rfc5083

 

Another suggestion is to= use the kek to wrap the hmac just like you wrapped the CEK.

 =

From: owner-ietf-sm= ime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 1:40 PM
To: Jim Schaad; ietf-smime@imc.org
Subject: RE: weak authentication issue with rfc5083

 

Hi Jim,

You can demonstrate know= ledge of both HMAC and KEK fairly simply per recipient e.g. by concatenating the KEK with the message HMAC and hashing the result. Since Mallet does not know th= e KEK they cannot compute the new hash. This fix works for both 3852 and 5083= .

 =

Trevor=

 =

From: Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Monday, May 05, 2008 1:23 PM
To: Trevor Freeman; ietf-smime@imc.org
Subject: RE: weak authentication issue with rfc5083

 

Trevor,

 =

The same issue also occu= rs for AuthenticatedData in RFC 3852.  This has been known for a long time.

 =

I am not sure how a demonstration of the KEK would solve this issue however.  The only way that I know to actually deal with this problem is to place the computed MAC under encryption for each recipient.

 =

Jim

 =

 =

From: owner-ietf-sm= ime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 12:52 PM
To: ietf-smime@imc.org
Subject: weak authentication issue with rfc5083

 

We have identified a potential for spoofing when using rfc5083.

 

Rfc5083 computes a message HMAC over the content using= the authenticated encryption algorithms. The message HMAC is calculated based o= n the content and the content encryption key (CEK).

 

A number of allowed key management techniques derive a= key encryption key (KEK) which can be used to authenticate the sender e.g. Static-Static Diffie Hellman, Kerberos shared secret, shared password. The = KEK is used to encrypt the CEK per recipient.

 

However when the integrity of the message is validated= via the message HMAC, the sender only demonstrates knowledge of the CEK to the recipient.

 

Any other recipient knows the CEK so can construct ano= ther message using the same CEK and compute the new HMAC and reuse the encrypted= KEK data from the original message. For example:

 

Alice sends a message to Bob and Mallet. Alice uses  different KEK’s  for both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using  his KEK. The message decrypts and the HMAC checks out so Bob th= ink the message is from Alice because only Bob and Alice know the KEK.

 

Mallet is the recipient of the original message so he can use his KEK to learn the message CEK. Mallet then  constructs a new message and encrypts it usi= ng the same CEK as the original message. Mallet copies Bobs  KEK recipien= t Info from Alice's message which contains the same encrypted CEK. Because Ma= llet knows the CEK he can also compute the correct HMAC for the new message. Mal= let sends the new message to Bob. Bob again uses his KEK to discover the CEK an= d successfully decrypts the message and the HMAC check out so Bob thinks this= new message is also from Alice.

 

This issue only applies when there are multiple recipients. The motivation to us= e the new authenticated encryption is to improve performance so solutions lik= e bifurcating messages to use different CEK or signing the message are counterproductive.

 

We need an additional structure to allow the sender to demonstrate knowledge of both the KEK and CEK per recipient when sending to multiple recipients.

What is the consensus to resolve this?

 

We can version 5083 to document the new structure or w= e can do document the new structure via a standalone document.

--_000_F767238E699C2E43895DDFB5F435088F0C2C07BE77DFMBX61exchan_-- From owner-ietf-smime@mail.imc.org Tue May 6 00:13:43 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 89CC33A6783 for ; Tue, 6 May 2008 00:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=0.6, 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 nOfNSp9EOI+9 for ; Tue, 6 May 2008 00:13:42 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 707313A6DFC for ; Tue, 6 May 2008 00:13:42 -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 m466lFJg072766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 23:47: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 m466lFBe072764; Mon, 5 May 2008 23:47: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 mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m466l9c3072736 for ; Mon, 5 May 2008 23:47:14 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 15187187B5; Tue, 6 May 2008 18:47:09 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPrXX8W1JpNt; Tue, 6 May 2008 18:47:08 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 496C0187B3; Tue, 6 May 2008 18:47:08 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 992C1E0808A; Tue, 6 May 2008 18:47:00 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JtGx2-0006Wi-Ff; Tue, 06 May 2008 18:47:00 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org, trevorf@EXCHANGE.MICROSOFT.com Subject: Re: weak authentication issue with rfc5083 In-Reply-To: Message-Id: Date: Tue, 06 May 2008 18:47:00 +1200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Trevor Freeman writes: >However when the integrity of the message is validated via the message HMAC, >the sender only demonstrates knowledge of the CEK to the recipient. > >Any other recipient knows the CEK so can construct another message using the >same CEK and compute the new HMAC and reuse the encrypted KEK data from the >original message. For example: Uhh, AuthEnv doesn't specify any use of HMAC, it can be used with HMAC if required (the other use is with a combined MAC+encrypt mode), but in the HMAC usage the HMAC and CEK keys are derived from a single key using a PRF, so knowledge of the CEK doesn't give you the HMAC key, and vice versa. It was specifically designed that way to prevent rollbacks where you strip off the MAC and rewrite it as plain encrypted data. Or have I misunderstood your point? Peter. From owner-ietf-smime@mail.imc.org Tue May 6 09:31: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 91F0B28C23E for ; Tue, 6 May 2008 09:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 yLGJ72+faJ4Z for ; Tue, 6 May 2008 09:31:28 -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 B49D23A6C2D for ; Tue, 6 May 2008 09:30:59 -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 m46GE8Ub004569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 May 2008 09:14: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 m46GE8FC004568; Tue, 6 May 2008 09:14: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 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 m46GE6Fx004551 for ; Tue, 6 May 2008 09:14:07 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 66171 invoked from network); 6 May 2008 16:13:55 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.241.4.90 with login) by smtp110.biz.mail.re2.yahoo.com with SMTP; 6 May 2008 16:13:55 -0000 X-YMail-OSG: u31WUQsVM1nVkZHTpNgj6yrTLx9AFLV8.eHejJp6UkRWNNMutuX_YfvCEkg6bah_KrlXItqWROCOOYEVlG5DLm_7bvkqmIOqWw59MtTXoc7w1IpQxd3ckwboniqEwtSH9v4- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "'Jim Schaad'" , "'Ietf-Smime'" References: <018301c8a3cb$38074bf0$0301a8c0@Wylie> <0fe601c8ad70$57e77c70$07b67550$@com> Subject: RE: New ASN.1 modules comments/questions Date: Tue, 6 May 2008 12:09:49 -0400 Organization: IECA, Inc. Message-ID: <025b01c8af93$9c6d6f10$0201a8c0@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.3198 In-Reply-To: <0fe601c8ad70$57e77c70$07b67550$@com> Thread-Index: Acijyzeq0RMiwCJnRHiuFMdEY7uJtQJkneRgAIucnJA= Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jim, No worries on the delay. Some thoughts on your responses. spt >> The definitions of AlgorithmIdentifier in the PKIX and SMIME modules >> are different - is there a reason for the difference? Does >it matter? >> In PKIX it's AlgorithmSet, in SMIME it's InfoObjectSet, in RFC2976 >> it's IOSet, in ANSI X9 docs it's also IOSet, and in X.509 it's >> SupportedAlgorithms. If it matters, then I guess I lean >towards what's >> in RFC2976 since it's already in an RFC. > >There is no effective difference between the two definitions. >The two differences are 1) the name of a parameter and 2) >comments. The name of the parameter makes no difference. >Just as the name of a parameter makes no difference if you are >writing a C function. The same is true for comments. I figured as much, but if we can control it I think they should be called the same thing. Don't really care what it's called just that they're called the same thing. >> ------------------- >> >> In the 3370 section, >> >> 2. You used alg- as tag for hash algs, sig- for signature >algs, kea- >> for key agreement algs, alg- for symmetric key encryption algs. I >> think it might be easier to figure out which algs go where >if the tag >> matches the type of algorithm like mda- for MessageDigestAlgorithms, >> sa- for SignatureAlgorithms, and kaa- for KeyAgreementAlgorithms. > >Thanks for suggesting some potential tags to be used. I agree >that we need some short simple notation to mark the different >types of algorithm objects. Since I'm using some of these tags in other IDs, I'll try to make sure we're in synch. >> 3. Could we change SymmetricKeyEncryptionAlgorithms to just >> KeyWrapAlgorithms and use kwa- as the tag? There's also a >> KeyWrapAlgorithm that I think is supposed to be the same as the >> SymmetricKeyEncryptionAlgorithms so one or the other can get deleted >> (if you delete the later change SupportKeyWrapAlgorithms to >> KeyWrapAlgorithms)? > >I have no problems with this change. There is a minor >question here about doing a good job of distinguishing Key >Wrap Algorithms and Key Transport Algorithms. > >I added the Symmetric to the front to distinguish from Key >Transport algorithms which, as the KEA algorithm suggest, can >also be thought of as >Key Encryption algorithms. The use of Key Wrap might be >sufficient to >distinguish between them, but CMS uses Key Encryption as the >name of these types of algorithms. > >Which is a better way to go? I think it's a toss up. I guess I was just confused because it wasn't clear to me whether the keyEncryptionAlgorithm in 3852 was constrainted by SymmetricKeyEncryption or KeyWrapAlgorithm. Now that I think about it the KeyWrapAlgorithms in this module is used to define the algorithm. This makes me think that adding comments above each IOset to say what it's constraining would help the reader a lot. >> 4. Shouldn't SymmetricKeyEncryptionAlgorithms be extensible? >> > >Welcome to a long philosophical discussion. > >There are two different places where this extensibility can be >placed. The two different locations imply different things. >This means that depending on how you look at things this >should or should not be extensible. > >If you place the extensibility here, you are saying that we >think that this document is going to be updated, and that we >are going to add new algorithms to this document. > >Alternatively, if you place the extensibility in CMS, you are >saying that we are going to define new algorithms by creating >new documents with new modules and they should be "imported" >into the CMS document in one manner or another. > >The compiler that we are working on has a planned directive to >allow for an object to be added to an extensible object set. >Part of the question at this point would be as follows. Where >should the new algorithm be added, in this document - thus >potentially effecting more than just CMS - or in CMS thus >limiting where the changes are set. > >My personal beliefs are: >- 1. New algorithms should be added by creating new documents >not by updating this document >- 2. Changes in algorithm sets should be as narrow as >possible - thus the updates should be done in CMS not here. > >The upshot of this is that I believe this object set is NOT >extensible, but the corresponding one in CMS should be extensible. I agree with you. We're already on this track because we've not updated 3370 every time a new alg comes along - what we've done is define a new ID with a new module. Don't see any reason to change from that course. >> ------------------- >> >> In the 3852 section, >> >> 2. Are you going to remove the version notations [[3:, [[4:, etc? > >It is my belief that having the version tags included adds >information to the ASN.1 module. Thus I plan on keeping them >unless I get some large objections. Still thinking about whether I should object ;) >> 3. For consistency with 3370, can we change DigestAlgorithmList to >> MessageDigestAlgorithms? > >I don't want these to have the same names. In the long run we >will do the >following: > DigestAlgorithmList ALGORITHM ::= {MessageDigestAlgorithms,...} > > >However I am open to the following: >- We create a standardized but descriptive method of naming >the sets of algorithms defined in a module - thus in 3370 we might say > CMSAlgs-MessageDigestAlgorithm > >- Do the suggested re-name here. Okay >> 10. For consistency, can we change KeyEncryptionAlgorithmList to be >> KeyEncryptionAlgorithms? > >The above note about matching the name in 3370 needs to be >taken into account. I used List (but could have used Set) but >I am not wedded to this. >I worry about using an 's' at the end as this could be a >sequence of algorithms as well. There exists a potential >confusion in the future. Sometimes we've used an 's' sometimes we've used 'list' - I guess I'd like them to be the same for no other reason than consistency. >> ------------------- >> >> In the 4998 section, >> >> 3. Why is Extensions and EXTENSION imported? > >To use a single standardized version, as with Attribute I might have missed it but I don't think it's used in the module? >> ------------------- >> >> In the 5035 section, >> >> 1. Why is Extensions and EXTENSION imported? >> > >See above I might have missed it but I don't think it's used in the module? >> 6. Is the note about the identical SecurityCategories encoding >> required >> anymore? > >I have no opinion one way or the other on this. Being >conservative says it >stays. Okay From owner-ietf-smime@mail.imc.org Tue May 6 10:20:59 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 7E61D3A6D19 for ; Tue, 6 May 2008 10:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 YUGTnK2L+KEG for ; Tue, 6 May 2008 10:20:58 -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 6AEE53A683D for ; Tue, 6 May 2008 10:20: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 m46H3bXf025804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 May 2008 10:03: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 m46H3bia025803; Tue, 6 May 2008 10:03: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 smtp109.biz.mail.re2.yahoo.com (smtp109.biz.mail.re2.yahoo.com [206.190.53.8]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m46H3avB025788 for ; Tue, 6 May 2008 10:03:36 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 62523 invoked from network); 6 May 2008 16:41:25 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.241.4.90 with login) by smtp109.biz.mail.re2.yahoo.com with SMTP; 6 May 2008 16:41:25 -0000 X-YMail-OSG: VN59W1QVM1kYaRMsqcNsLGjjtHSuRqGwU77yI.XRc.EtcTB9fgSNWUI4NoHwALnlS450vXQkq8EDX2Xe19kGExRsKVVsB9x5ksvm7rbj2B69_1ZhjaPSBH84um84jY4pRCw- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "'Tony Capel'" , "'Paul Hoffman'" , References: <023701c8aef2$ad31a650$0201a8c0@Wylie> <004301c8aef7$bcafeba0$02b5a8c0@tony> Subject: RE: S/MIME v3.2 IDs key size text Date: Tue, 6 May 2008 12:37:19 -0400 Organization: IECA, Inc. Message-ID: <025e01c8af97$73f5a4e0$0201a8c0@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.3198 In-Reply-To: <004301c8aef7$bcafeba0$02b5a8c0@tony> Thread-Index: AcitjLJkvgon3zgMT46W137Z98cRiQBUq31QAASyTyAAAQJGwAAhkymw Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tony, Inline... spt >-----Original Message----- >From: owner-ietf-smime@mail.imc.org >[mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Tony Capel >Sent: Monday, May 05, 2008 5:34 PM >To: 'Turner, Sean P.'; 'Paul Hoffman'; ietf-smime@imc.org >Subject: RE: S/MIME v3.2 IDs key size text > > >Sean: > >Agreed, the text in 3850bis and 3851bis needs to align. I >have no problems with support for smaller key sizes. You got it. I was just trying to say we need to keep the two algined. >I expect constraints on key size to be implemented by the >certificate issuer anyway. If you get a 512 key in a cert you >trust you must be able to use it, no? Originally, I thought the answer really was no, but I think for interop with v3 and v3.1 we need to say yes. If you get a 512 key in a cert from a source you trust, then you can decide to not use it but it's not because you don't trust the source it's because of some other reason. I can see where maybe short lived certs are used because the info gets stale quickly, they need to sign/verify really quickly, etc. I am a little concerned about the FIP-140 issue though. Just a thought ... since we've now got a way to indicate + and - with requirements should we apply it the key sizes in 3850bis? That way people will have a hint that in the next update the shorter keys will likely become not so welcome and large keys more so? 0 < key size < 511 : MUST NOT 512 < key size < 1023 : SHOULD- 1024 < key size < 2048 : MUST 2049 < key size < 4096 : MAY >Tony > >| -----Original Message----- >| From: owner-ietf-smime@mail.imc.org >| [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Turner, Sean P. >| Sent: May 5, 2008 4:58 PM >| To: 'Tony Capel'; 'Paul Hoffman'; ietf-smime@imc.org >| Subject: RE: S/MIME v3.2 IDs key size text >| >| >| >| Tony, >| >| There was a comment from Paul against the text you cite from >3850bis. >| He objected to moving the lower bounds from 512 to 1024. I >figured I'd >| post both -02 drafts once we knocked this issue out. >| >| spt >| >| >-----Original Message----- >| >From: Tony Capel [mailto:capel@comgate.com] >| >Sent: Monday, May 05, 2008 4:09 PM >| >To: 'Paul Hoffman'; 'Turner, Sean P.'; ietf-smime@imc.org >| >Subject: RE: S/MIME v3.2 IDs key size text >| > >| >All: >| > >| >I agree that deleting " namely 1024 bits" from the first >sentence of >| >the proposed security considerations section paragraph is >good. The >| >second "1024" >| >in the proposed paragraph is not a problem for me since it is not >| >"normative". >| > >| >With respect to section 4.1 (Key Pair Generation). Is it >intended to >| >change the title of this section? The second paragraph of the >| >current text in 3851bis-01.txt begins "If an S/MIME agent needs to >| >generate ...". So if the S/MIME agent does NOT need to >generate keys >| >(and this is typically the case, most enrollment & key >generation are >| >done externally to messaging clients) the balance of this paragraph >| >(which mentions the key sizes) is not normative (as >currently drafted >| >- its quite possible that the last sentence of this >paragraph should >| >have been in a separate paragraph). Key generation >requirements are >| >normally (hopefully!) cited in the corresponding CP, where things >| >such as required key sizes, where they are generated (locally or at >| >the CA), FIPS-140 Level, etc. should be (!!) explicitly >identified. >| >Maybe the second paragraph of >| >4.1 could be replaced with a simple statement: >| > >| >"If an S/MIME agent needs to generate one or more key pairs, each >| >SHOULD be generated according to the corresponding certificate >| >policy, refer for example to [RFC3647]." >| > >| >The proposed text, and the discussion so far, is really speaking >| >about "what range of RSA key sizes" needs to be supported. We are >| >NOT providing security advice, we are just trying to ensure >that most >| >smime v3.2 implementations will interwork in the typical >environments >| >expected "in the wild" >| >(and special environments will be understood by purchasers >anyway, so >| >we likely need not worry about high security applications - >only the >| >general "public" >| >environments). >| > >| >A similar issue is already addressed in CERT v3.2 ( >| >draft-ietf-smime-3850bis-01.txt ) in Section 4.3 for certificate >| >validation. >| >We might consider copying the last sentence of CERT v3.2 Sec >| >4.3 to the end of sections 2.2 and 2.3 (just before the Notes): >| > >| > "Key sizes from 1024 bits to 2048 bits MUST be supported." >| > >| >This would also have the advantage of aligning CERT and MSG. >| > >| >Tony >| > >| > >| >| -----Original Message----- >| >| From: owner-ietf-smime@mail.imc.org >| >| [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Paul Hoffman >| >| Sent: May 3, 2008 10:08 PM >| >| To: Turner, Sean P.; ietf-smime@imc.org >| >| Subject: RE: S/MIME v3.2 IDs key size text >| >| >| >| >| >| >| >| At 8:51 PM -0400 5/3/08, Turner, Sean P. wrote: >| >| >I think if we struck ", namely 1024 bits" from the text in >| >| the security >| >| >considerations that it's still a true statement and we >| >won't have to >| >| >change it every time we update the spec. >| >| >| >| I'm OK with that, but I also feel that if we're updating >| the minimum >| >| mandatory signing length, it is trivial to update the Security >| >| Considerations as well. >| >| >| > >| > From owner-ietf-smime@mail.imc.org Tue May 6 10:59:40 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 219123A6839 for ; Tue, 6 May 2008 10:59:40 -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=[AWL=-0.000, 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 nMsHLcX2dpGy for ; Tue, 6 May 2008 10:59: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 42E1228C42E for ; Tue, 6 May 2008 10:59:36 -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 m46Hj1sv042368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 May 2008 10:45:01 -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 m46Hj1BM042367; Tue, 6 May 2008 10:45:01 -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 [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m46Hj0dR042357 for ; Tue, 6 May 2008 10:45:01 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 7A69B28C37A; Tue, 6 May 2008 10:45: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-rfc3278-update-04.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080506174501.7A69B28C37A@core3.amsl.com> Date: Tue, 6 May 2008 10:45: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 : Update to Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) Author(s) : S. Turner Filename : draft-ietf-smime-rfc3278-update-04.txt Pages : 28 Date : 2008-5-6 RFC 3278 describes how to use Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic Message Syntax (CMS). This document updates RFC 3278 to add support for the SHA2 family of hash algorithms, Elliptic Curve Digital Signature Algorithm (ECDSA) 224-512, and Key Derivation Functions (KDFs) that utilize SHA2 algorithms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc3278-update-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. --NextPart Content-Type: Message/External-body; name="draft-ietf-smime-rfc3278-update-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-5-6103457.I-D@ietf.org> --NextPart-- From owner-ietf-smime@mail.imc.org Tue May 6 12:48:43 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 0C6FE3A67D0 for ; Tue, 6 May 2008 12:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_37=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 n+iaPFeuPy6d for ; Tue, 6 May 2008 12:48:42 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id ECECC3A681B for ; Tue, 6 May 2008 12:48:41 -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 m46JTmZp087269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 May 2008 12:29:48 -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 m46JTmHW087268; Tue, 6 May 2008 12:29:48 -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 m46JTkf5087251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 6 May 2008 12:29:48 -0700 (MST) (envelope-from ietf@augustcellars.com) Received: from GALATIONS (unknown [207.202.179.27]) by smtp4.pacifier.net (Postfix) with ESMTP id 0FCDC6A586; Tue, 6 May 2008 12:29:43 -0700 (PDT) From: "Jim Schaad" To: "'Peter Gutmann'" , , References: In-Reply-To: Subject: RE: weak authentication issue with rfc5083 Date: Tue, 6 May 2008 12:29:43 -0700 Message-ID: <14c501c8afaf$899e2700$9cda7500$@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: AcivRWhy9LBxPdCQTUOMP8nN1uv26gAab23A Content-Language: en-us Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter, I believe you have misunderstood the issue that Trevor raised. His problem is: 1. I send you and him a single Authenticated Message. 2. He takes the common CEK in the original message, uses it to create a MAC on an new message and then sends it on to you. As is always true with Authenticated messages, there is no proof of origin. He worries that you might be confused and believe the second messages was from me rather than from him. Since they both use the same CEK that is not a factor that could be used to distinguish them. Jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf- > smime@mail.imc.org] On Behalf Of Peter Gutmann > Sent: Monday, May 05, 2008 11:47 PM > To: ietf-smime@imc.org; trevorf@EXCHANGE.MICROSOFT.com > Subject: Re: weak authentication issue with rfc5083 > > > Trevor Freeman writes: > > >However when the integrity of the message is validated via the message > HMAC, > >the sender only demonstrates knowledge of the CEK to the recipient. > > > >Any other recipient knows the CEK so can construct another message > using the > >same CEK and compute the new HMAC and reuse the encrypted KEK data > from the > >original message. For example: > > Uhh, AuthEnv doesn't specify any use of HMAC, it can be used with HMAC > if > required (the other use is with a combined MAC+encrypt mode), but in > the HMAC > usage the HMAC and CEK keys are derived from a single key using a PRF, > so > knowledge of the CEK doesn't give you the HMAC key, and vice versa. It > was > specifically designed that way to prevent rollbacks where you strip off > the > MAC and rewrite it as plain encrypted data. Or have I misunderstood > your > point? > > Peter. From owner-ietf-smime@mail.imc.org Tue May 6 12:50:24 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 153B13A702F for ; Tue, 6 May 2008 12:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 o9yrH6X9tKJE for ; Tue, 6 May 2008 12:50:06 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id A18733A67D0 for ; Tue, 6 May 2008 12:50:05 -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 m46JUppJ087726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 May 2008 12:30: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 m46JUpic087725; Tue, 6 May 2008 12:30: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 smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m46JUnQW087709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 6 May 2008 12:30:50 -0700 (MST) (envelope-from ietf@augustcellars.com) Received: from GALATIONS (unknown [207.202.179.27]) by smtp2.pacifier.net (Postfix) with ESMTP id 82B7E6B388; Tue, 6 May 2008 12:30:47 -0700 (PDT) From: "Jim Schaad" To: "'Trevor Freeman'" , References: <12c801c8aeed$ddd47670$997d6350$@com> <130901c8af00$b698b0e0$23ca12a0$@com> In-Reply-To: Subject: RE: weak authentication issue with rfc5083 Date: Tue, 6 May 2008 12:30:47 -0700 Message-ID: <14c601c8afaf$af919370$0eb4ba50$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_14C7_01C8AF75.0332BB70" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aciu6YBkwNV9yBxhQNWEO1d1mLywFgABCUHgAAAYJfAAAU9AUAADVTBQAAAPh/AAK7AMYA== Content-Language: en-us Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. ------=_NextPart_000_14C7_01C8AF75.0332BB70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I would have an issue with this since could be silently stripped without the recipients or senders knowledge. Thus I don't see it as solving your problem. Jim From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 3:42 PM To: Jim Schaad; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Not if you send the recipient info's with the encrypted hmac as an unauthenticated attribute. Trevor From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, May 05, 2008 3:38 PM To: Trevor Freeman; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 The downside of this would be that you could no longer do one pass encoding. You would need to compute the HMAC prior to computing the recipient infos. Jim From: Trevor Freeman [mailto:trevorf@exchange.microsoft.com] Sent: Monday, May 05, 2008 2:03 PM To: Trevor Freeman; Jim Schaad; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Another suggestion is to use the kek to wrap the hmac just like you wrapped the CEK. From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 1:40 PM To: Jim Schaad; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Hi Jim, You can demonstrate knowledge of both HMAC and KEK fairly simply per recipient e.g. by concatenating the KEK with the message HMAC and hashing the result. Since Mallet does not know the KEK they cannot compute the new hash. This fix works for both 3852 and 5083. Trevor From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, May 05, 2008 1:23 PM To: Trevor Freeman; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Trevor, The same issue also occurs for AuthenticatedData in RFC 3852. This has been known for a long time. I am not sure how a demonstration of the KEK would solve this issue however. The only way that I know to actually deal with this problem is to place the computed MAC under encryption for each recipient. Jim From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 12:52 PM To: ietf-smime@imc.org Subject: weak authentication issue with rfc5083 We have identified a potential for spoofing when using rfc5083. Rfc5083 computes a message HMAC over the content using the authenticated encryption algorithms. The message HMAC is calculated based on the content and the content encryption key (CEK). A number of allowed key management techniques derive a key encryption key (KEK) which can be used to authenticate the sender e.g. Static-Static Diffie Hellman, Kerberos shared secret, shared password. The KEK is used to encrypt the CEK per recipient. However when the integrity of the message is validated via the message HMAC, the sender only demonstrates knowledge of the CEK to the recipient. Any other recipient knows the CEK so can construct another message using the same CEK and compute the new HMAC and reuse the encrypted KEK data from the original message. For example: Alice sends a message to Bob and Mallet. Alice uses different KEK's for both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using his KEK. The message decrypts and the HMAC checks out so Bob think the message is from Alice because only Bob and Alice know the KEK. Mallet is the recipient of the original message so he can use his KEK to learn the message CEK. Mallet then constructs a new message and encrypts it using the same CEK as the original message. Mallet copies Bobs KEK recipient Info from Alice's message which contains the same encrypted CEK. Because Mallet knows the CEK he can also compute the correct HMAC for the new message. Mallet sends the new message to Bob. Bob again uses his KEK to discover the CEK and successfully decrypts the message and the HMAC check out so Bob thinks this new message is also from Alice. This issue only applies when there are multiple recipients. The motivation to use the new authenticated encryption is to improve performance so solutions like bifurcating messages to use different CEK or signing the message are counterproductive. We need an additional structure to allow the sender to demonstrate knowledge of both the KEK and CEK per recipient when sending to multiple recipients. What is the consensus to resolve this? We can version 5083 to document the new structure or we can do document the new structure via a standalone document. ------=_NextPart_000_14C7_01C8AF75.0332BB70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would have an issue = with this since could be silently stripped without the recipients or senders = knowledge.  Thus I don’t see it as solving your problem.

 

Jim

 

 

From:= owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 3:42 PM
To: Jim Schaad; ietf-smime@imc.org
Subject: RE: weak authentication issue with = rfc5083

 

Not if you send the = recipient info’s with the encrypted hmac as an unauthenticated = attribute.

 

Trevor

 

From:= Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Monday, May 05, 2008 3:38 PM
To: Trevor Freeman; ietf-smime@imc.org
Subject: RE: weak authentication issue with = rfc5083

 

The downside of this = would be that you could no longer do one pass encoding.  You would need to = compute the HMAC prior to computing the recipient infos.

 

Jim

 

 

From:= Trevor = Freeman [mailto:trevorf@exchange.microsoft.com]
Sent: Monday, May 05, 2008 2:03 PM
To: Trevor Freeman; Jim Schaad; ietf-smime@imc.org
Subject: RE: weak authentication issue with = rfc5083

 

Another suggestion is = to use the kek to wrap the hmac just like you wrapped the = CEK.

 

From:= owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 1:40 PM
To: Jim Schaad; ietf-smime@imc.org
Subject: RE: weak authentication issue with = rfc5083

 

Hi = Jim,

You can demonstrate = knowledge of both HMAC and KEK fairly simply per recipient e.g. by concatenating the = KEK with the message HMAC and hashing the result. Since Mallet does not know = the KEK they cannot compute the new hash. This fix works for both 3852 and = 5083.

 

Trevor

 

From:= Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Monday, May 05, 2008 1:23 PM
To: Trevor Freeman; ietf-smime@imc.org
Subject: RE: weak authentication issue with = rfc5083

 

Trevor,

 

The same issue also = occurs for AuthenticatedData in RFC 3852.  This has been known for a long = time.

 

I am not sure how a = demonstration of the KEK would solve this issue however.  The only way that I = know to actually deal with this problem is to place the computed MAC under = encryption for each recipient.

 

Jim

 

 

From:= owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 12:52 PM
To: ietf-smime@imc.org
Subject: weak authentication issue with = rfc5083

 

We have identified a potential for spoofing when = using rfc5083.

 

Rfc5083 computes a message HMAC over the content = using the authenticated encryption algorithms. The message HMAC is calculated = based on the content and the content encryption key (CEK).

 

A number of allowed key management techniques = derive a key encryption key (KEK) which can be used to authenticate the sender e.g. Static-Static Diffie Hellman, Kerberos shared secret, shared password. = The KEK is used to encrypt the CEK per recipient.

 

However when the integrity of the message is = validated via the message HMAC, the sender only demonstrates knowledge of the CEK to = the recipient.

 

Any other recipient knows the CEK so can construct = another message using the same CEK and compute the new HMAC and reuse the = encrypted KEK data from the original message. For example:

 

Alice sends a message to Bob and Mallet. Alice uses  different = KEK’s  for both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using  = his KEK. The message decrypts and the HMAC checks out so Bob think the = message is from Alice because only Bob and Alice know the = KEK.

 =

Mallet is the recipient of the original message so he can use his KEK to learn = the message CEK. Mallet then  constructs a new message and encrypts it = using the same CEK as the original message. Mallet copies Bobs  KEK = recipient Info from Alice's message which contains the same encrypted CEK. Because = Mallet knows the CEK he can also compute the correct HMAC for the new message. = Mallet sends the new message to Bob. Bob again uses his KEK to discover the CEK = and successfully decrypts the message and the HMAC check out so Bob thinks = this new message is also from Alice.

 =

This issue only applies when there are multiple recipients. The motivation to = use the new authenticated encryption is to improve performance so solutions = like bifurcating messages to use different CEK or signing the message are = counterproductive.

 

We need an additional structure to allow the sender = to demonstrate knowledge of both the KEK and CEK per recipient when sending = to multiple recipients.

What is the consensus to resolve this? =

 

We can version 5083 to document the new structure = or we can do document the new structure via a standalone document.

------=_NextPart_000_14C7_01C8AF75.0332BB70-- From owner-ietf-smime@mail.imc.org Tue May 6 12:50:42 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 403DC3A700C for ; Tue, 6 May 2008 12:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, 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 4phGemuWzh7l for ; Tue, 6 May 2008 12:50:41 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 341713A6AE0 for ; Tue, 6 May 2008 12:50: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 m46JPA9L085140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 May 2008 12:25:10 -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 m46JPA48085139; Tue, 6 May 2008 12:25:10 -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.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m46JP8Cr085117 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Tue, 6 May 2008 12:25:09 -0700 (MST) (envelope-from trevorf@exchange.microsoft.com) Received: from df-bhd-01.exchange.corp.microsoft.com (157.54.111.57) by DF-GWY-07.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 6 May 2008 12:25:49 -0700 Received: from df-mlt-02.exchange.corp.microsoft.com (157.54.94.20) by df-bhd-01.exchange.corp.microsoft.com (157.54.111.57) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 6 May 2008 12:25:49 -0700 Received: from DF-MBX-61.exchange.corp.microsoft.com ([169.254.2.227]) by DF-MLT-02.exchange.corp.microsoft.com ([157.54.94.20]) with mapi; Tue, 6 May 2008 12:25:48 -0700 From: Trevor Freeman To: pgut001 , "ietf-smime@imc.org" Date: Tue, 6 May 2008 19:25:05 +0000 Subject: RE: weak authentication issue with rfc5083 Thread-Topic: weak authentication issue with rfc5083 Thread-Index: Aciu6YBkwNV9yBxhQNWEO1d1mLywFgAW5sp3ABoHyLA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I should have use MAC to be more accurate. 5083 generates a MAC using the message contents and the CEK. If there are multiple recipients - all know the CEK so any can generate new= messages with the same CEK. So you only can presume the message is from on= e of the group who know the CEK but you don't know which one. You could have used a pair wise shared secret to protect the CEK but 5083 d= oes not define how to use the pair wise shared secret to also authenticate = the sender. If the sender encrypted the MAC using the KEK and attached that= to the message as an unauthenticated attribute the receiver can authentica= te the sender. -----Original Message----- From: pgut001 [mailto:pgut001@cs.auckland.ac.nz] Sent: Monday, May 05, 2008 11:47 PM To: ietf-smime@imc.org; Trevor Freeman Subject: Re: weak authentication issue with rfc5083 Trevor Freeman writes: >However when the integrity of the message is validated via the message HMA= C, >the sender only demonstrates knowledge of the CEK to the recipient. > >Any other recipient knows the CEK so can construct another message using t= he >same CEK and compute the new HMAC and reuse the encrypted KEK data from th= e >original message. For example: Uhh, AuthEnv doesn't specify any use of HMAC, it can be used with HMAC if required (the other use is with a combined MAC+encrypt mode), but in the HM= AC usage the HMAC and CEK keys are derived from a single key using a PRF, so knowledge of the CEK doesn't give you the HMAC key, and vice versa. It was specifically designed that way to prevent rollbacks where you strip off the MAC and rewrite it as plain encrypted data. Or have I misunderstood your point? Peter. From owner-ietf-smime@mail.imc.org Tue May 6 14:11:20 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 608D63A6C62 for ; Tue, 6 May 2008 14:11:20 -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 sww9JRDBbi4c for ; Tue, 6 May 2008 14:11:19 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 5DC113A6844 for ; Tue, 6 May 2008 14:11: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 m46Ksg8G024071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 May 2008 13:54:42 -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 m46KsgeK024069; Tue, 6 May 2008 13:54:42 -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.202] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m46KsdQu024048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 May 2008 13:54:40 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 6 May 2008 13:54:37 -0700 To: ietf-smime@imc.org From: Paul Hoffman Subject: Patent disclosure of interest Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From owner-ietf-smime@mail.imc.org Tue May 6 14:49:35 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 7D4C928C4A6 for ; Tue, 6 May 2008 14:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 b6hpwuSO0RDJ for ; Tue, 6 May 2008 14:49:27 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 5A49628C4B2 for ; Tue, 6 May 2008 14:49:26 -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 m46LTj8X039168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 May 2008 14:29: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 m46LTjJa039166; Tue, 6 May 2008 14:29: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.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m46LThw7039143 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Tue, 6 May 2008 14:29:44 -0700 (MST) (envelope-from trevorf@exchange.microsoft.com) Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) by DF-GWY-07.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 6 May 2008 14:30:19 -0700 Received: from df-mlt-02.exchange.corp.microsoft.com (157.54.94.20) by df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 6 May 2008 14:30:19 -0700 Received: from DF-MBX-61.exchange.corp.microsoft.com ([169.254.2.227]) by DF-MLT-02.exchange.corp.microsoft.com ([157.54.94.20]) with mapi; Tue, 6 May 2008 14:30:17 -0700 From: Trevor Freeman To: Jim Schaad , "ietf-smime@imc.org" Date: Tue, 6 May 2008 21:29:34 +0000 Subject: RE: weak authentication issue with rfc5083 Thread-Topic: weak authentication issue with rfc5083 Thread-Index: Aciu6YBkwNV9yBxhQNWEO1d1mLywFgABCUHgAAAYJfAAAU9AUAADVTBQAAAPh/AAK7AMYAACpw8g Message-ID: References: <12c801c8aeed$ddd47670$997d6350$@com> <130901c8af00$b698b0e0$23ca12a0$@com> <14c601c8afaf$af919370$0eb4ba50$@com> In-Reply-To: <14c601c8afaf$af919370$0eb4ba50$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_F767238E699C2E43895DDFB5F435088F0C2C102509DFMBX61exchan_" MIME-Version: 1.0 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_000_F767238E699C2E43895DDFB5F435088F0C2C102509DFMBX61exchan_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The same is true of the MAC because that is sent as unauthenticated data. T= he recipients computes the MAC then compares it to the unprotected value se= nt with the message. The computed value and the transmitted value have to m= atch otherwise it's an authentication failure. If you strip or alter the M= AC the recipient detects problem. This proposal has exactly the same characteristics. Trevor From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Tuesday, May 06, 2008 12:31 PM To: Trevor Freeman; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 I would have an issue with this since could be silently stripped without th= e recipients or senders knowledge. Thus I don't see it as solving your pro= blem. Jim From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 3:42 PM To: Jim Schaad; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Not if you send the recipient info's with the encrypted hmac as an unauthen= ticated attribute. Trevor From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, May 05, 2008 3:38 PM To: Trevor Freeman; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 The downside of this would be that you could no longer do one pass encoding= . You would need to compute the HMAC prior to computing the recipient info= s. Jim From: Trevor Freeman [mailto:trevorf@exchange.microsoft.com] Sent: Monday, May 05, 2008 2:03 PM To: Trevor Freeman; Jim Schaad; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Another suggestion is to use the kek to wrap the hmac just like you wrapped= the CEK. From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 1:40 PM To: Jim Schaad; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Hi Jim, You can demonstrate knowledge of both HMAC and KEK fairly simply per recipi= ent e.g. by concatenating the KEK with the message HMAC and hashing the res= ult. Since Mallet does not know the KEK they cannot compute the new hash. T= his fix works for both 3852 and 5083. Trevor From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, May 05, 2008 1:23 PM To: Trevor Freeman; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Trevor, The same issue also occurs for AuthenticatedData in RFC 3852. This has bee= n known for a long time. I am not sure how a demonstration of the KEK would solve this issue however= . The only way that I know to actually deal with this problem is to place = the computed MAC under encryption for each recipient. Jim From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 12:52 PM To: ietf-smime@imc.org Subject: weak authentication issue with rfc5083 We have identified a potential for spoofing when using rfc5083. Rfc5083 computes a message HMAC over the content using the authenticated en= cryption algorithms. The message HMAC is calculated based on the content an= d the content encryption key (CEK). A number of allowed key management techniques derive a key encryption key (= KEK) which can be used to authenticate the sender e.g. Static-Static Diffie= Hellman, Kerberos shared secret, shared password. The KEK is used to encry= pt the CEK per recipient. However when the integrity of the message is validated via the message HMAC= , the sender only demonstrates knowledge of the CEK to the recipient. Any other recipient knows the CEK so can construct another message using th= e same CEK and compute the new HMAC and reuse the encrypted KEK data from t= he original message. For example: Alice sends a message to Bob and Mallet. Alice uses different KEK's for b= oth Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using his KEK.= The message decrypts and the HMAC checks out so Bob think the message is f= rom Alice because only Bob and Alice know the KEK. Mallet is the recipient of the original message so he can use his KEK to le= arn the message CEK. Mallet then constructs a new message and encrypts it = using the same CEK as the original message. Mallet copies Bobs KEK recipie= nt Info from Alice's message which contains the same encrypted CEK. Because= Mallet knows the CEK he can also compute the correct HMAC for the new mess= age. Mallet sends the new message to Bob. Bob again uses his KEK to discove= r the CEK and successfully decrypts the message and the HMAC check out so B= ob thinks this new message is also from Alice. This issue only applies when there are multiple recipients. The motivation = to use the new authenticated encryption is to improve performance so soluti= ons like bifurcating messages to use different CEK or signing the message a= re counterproductive. We need an additional structure to allow the sender to demonstrate knowledg= e of both the KEK and CEK per recipient when sending to multiple recipients= . What is the consensus to resolve this? We can version 5083 to document the new structure or we can do document the= new structure via a standalone document. --_000_F767238E699C2E43895DDFB5F435088F0C2C102509DFMBX61exchan_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The same is true of the = MAC because that is sent as unauthenticated data. The recipients computes the MAC then compares it to the unprotected value sent with the message. The computed va= lue and the transmitted value have to match otherwise it’s an authenticat= ion failure.  If you strip or alter the MAC the recipient detects problem.

This proposal has exactl= y the same characteristics.

 =

Trevor=

 =

From: Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Tuesday, May 06, 2008 12:31 PM
To: Trevor Freeman; ietf-smime@imc.org
Subject: RE: weak authentication issue with rfc5083

 

I would have an issue wi= th this since could be silently stripped without the recipients or senders knowledg= e.  Thus I don’t see it as solving your problem.<= /p>

 =

Jim

 =

 =

From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 3:42 PM
To: Jim Schaad; ietf-smime@imc.org
Subject: RE: weak authentication issue with rfc5083

 

Not if you send the reci= pient info’s with the encrypted hmac as an unauthenticated attribute.<= /o:p>

 =

Trevor=

 =

From: Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Monday, May 05, 2008 3:38 PM
To: Trevor Freeman; ietf-smime@imc.org
Subject: RE: weak authentication issue with rfc5083

 

The downside of this wou= ld be that you could no longer do one pass encoding.  You would need to comp= ute the HMAC prior to computing the recipient infos.

 =

Jim

 =

 =

From: Trevor Freema= n [mailto:trevorf@exchange.microsoft.com]
Sent: Monday, May 05, 2008 2:03 PM
To: Trevor Freeman; Jim Schaad; ietf-smime@imc.org
Subject: RE: weak authentication issue with rfc5083

 

Another suggestion is to= use the kek to wrap the hmac just like you wrapped the CEK.

 =

From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 1:40 PM
To: Jim Schaad; ietf-smime@imc.org
Subject: RE: weak authentication issue with rfc5083

 

Hi Jim,

You can demonstrate know= ledge of both HMAC and KEK fairly simply per recipient e.g. by concatenating the KEK with the message HMAC and hashing the result. Since Mallet does not know th= e KEK they cannot compute the new hash. This fix works for both 3852 and 5083= .

 =

Trevor=

 =

From: Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Monday, May 05, 2008 1:23 PM
To: Trevor Freeman; ietf-smime@imc.org
Subject: RE: weak authentication issue with rfc5083

 

Trevor,

 =

The same issue also occu= rs for AuthenticatedData in RFC 3852.  This has been known for a long time.

 =

I am not sure how a demonstration of the KEK would solve this issue however.  The only way that I know to actually deal with this problem is to place the computed MAC under encryption for each recipient.

 =

Jim

 =

 =

From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 12:52 PM
To: ietf-smime@imc.org
Subject: weak authentication issue with rfc5083

 

We have identified a potential for spoofing when using rfc5083.

 

Rfc5083 computes a message HMAC over the content using= the authenticated encryption algorithms. The message HMAC is calculated based o= n the content and the content encryption key (CEK).

 

A number of allowed key management techniques derive a= key encryption key (KEK) which can be used to authenticate the sender e.g. Static-Static Diffie Hellman, Kerberos shared secret, shared password. The = KEK is used to encrypt the CEK per recipient.

 

However when the integrity of the message is validated= via the message HMAC, the sender only demonstrates knowledge of the CEK to the recipient.

 

Any other recipient knows the CEK so can construct ano= ther message using the same CEK and compute the new HMAC and reuse the encrypted= KEK data from the original message. For example:

 

Alice sends a message to Bob and Mallet. Alice uses  different KEK’s  for both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using  his KEK. The message decrypts and the HMAC checks out so Bob th= ink the message is from Alice because only Bob and Alice know the KEK.

 

Mallet is the recipient of the original message so he can use his KEK to learn the message CEK. Mallet then  constructs a new message and encrypts it usi= ng the same CEK as the original message. Mallet copies Bobs  KEK recipien= t Info from Alice's message which contains the same encrypted CEK. Because Ma= llet knows the CEK he can also compute the correct HMAC for the new message. Mal= let sends the new message to Bob. Bob again uses his KEK to discover the CEK an= d successfully decrypts the message and the HMAC check out so Bob thinks this= new message is also from Alice.

 

This issue only applies when there are multiple recipients. The motivation to us= e the new authenticated encryption is to improve performance so solutions lik= e bifurcating messages to use different CEK or signing the message are counterproductive.

 

We need an additional structure to allow the sender to demonstrate knowledge of both the KEK and CEK per recipient when sending to multiple recipients.

What is the consensus to resolve this?

 

We can version 5083 to document the new structure or w= e can do document the new structure via a standalone document.

--_000_F767238E699C2E43895DDFB5F435088F0C2C102509DFMBX61exchan_-- From owner-ietf-smime@mail.imc.org Wed May 7 07:25: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 646D528C682 for ; Wed, 7 May 2008 07:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 P5a00H3IUPtc for ; Wed, 7 May 2008 07:23:47 -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 090EF28C6DE for ; Wed, 7 May 2008 07:20: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 m47E0gWr051578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 May 2008 07:00:42 -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 m47E0g4V051576; Wed, 7 May 2008 07:00:42 -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.nist.gov (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m47E0ecV051560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 7 May 2008 07:00:41 -0700 (MST) (envelope-from tim.polk@nist.gov) Received: from [192.168.15.166] (bethany.ncsl.nist.gov [129.6.52.15]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m47E0WpT018739; Wed, 7 May 2008 10:00:32 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) References: <7.0.1.0.2.20080506160054.0251ad30@nist.gov> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <89EDB6AD-61F0-4D14-9AF7-F4A79AE2481F@nist.gov> Content-Transfer-Encoding: 7bit From: Tim Polk Subject: Fwd: NIST Identity-Based Encryption Workshop- Registration Deadline Approaching Date: Wed, 7 May 2008 10:00:36 -0400 To: saag@mit.edu, S-MIME / IETF X-Mailer: Apple Mail (2.752.2) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, My apologies for a brief advertisement... I am forwarding this workshop announcement since IBE documents are currently progressing through one of the security area working groups, and because I am always anxious to see the needs of the Internet community considered by NIST in our standardization activities. Attendance is one way to ensure your voice is heard. If you have a strong opinion about IBE and are unable to attend, please let me know so I can pass it along! Note that the early registration fee is only available through the end of the week. Thanks, Tim Polk Begin forwarded message: > From: Andrew Regenscheid > Date: May 6, 2008 4:08:35 PM EDT > To: Multiple recipients of list > Subject: NIST Identity-Based Encryption Workshop- Registration > Deadline Approaching > Reply-To: ibe@nist.gov > > > Applications of Pairing-Based Cryptography: Identity-Based > Encryption and Beyond > June 3-4, 2008 > NIST, Gaithersburg, MD > > The early registration deadline is approaching! Please join us at > the workshop and help NIST direct its future work on identity-based > encryption. > > This workshop brings together academia, government and industry to > explore innovative and practical applications of pairing-based > cryptography. Pairings have been used to create identity-based > encryption schemes, but are also a powerful tool for solving other > cryptographic problems. We hope to encourage the development of > new security applications and communication between researchers, > developers and users. In addition to presentations, the workshop > will facilitate panel discussions among invited experts and > workshop participants. NIST will seek guidance from workshop > presenters, panelists and attendees to direct its future work in > this area of cryptography, including possible standards work. > > Dr. Matt Franklin, co-inventor of one of the original identity- > based encryption schemes, will be presenting a keynote address > entitled "An Introduction to Identity Based Encryption." Dr. Brent > Waters will be presenting a keynote address entitled "Functional > Encryption: Beyond Public Key Cryptography." The workshop program > also includes two panel discussions and 13 presentations from > researchers from around the world. The complete agenda has been > posted at http://www.nist.gov/ibe. > > The early registration deadline for the NIST Applications of > Pairing Based Cryptography workshop is quickly approaching. The > registration fee is $110 until May 10th, and $145 until May 27th. > Please note that these fees have been reduced due to NIST no longer > being able to provide food and beverages. Voltage Security and > Trend Micro will be sponsoring the morning and afternoon breaks. > However, each attendee will be responsible for his/her own lunch. > NIST has a full-service cafeteria adjacent to the Green Auditorium. > Please note the cafeteria does not take any credit or debit cards. > Please be prepared with cash. > > More details on the workshop are available at http://www.nist.gov/ibe > > > From owner-ietf-smime@mail.imc.org Fri May 9 07:02: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 D2E5F3A67FA for ; Fri, 9 May 2008 07:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 fKVohn2+YDyX for ; Fri, 9 May 2008 07:02:19 -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 92A353A684B for ; Fri, 9 May 2008 07:02:13 -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 m49DPpLq009453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 May 2008 06:25: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 m49DPpUE009452; Fri, 9 May 2008 06:25: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 mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m49DPnka009423 for ; Fri, 9 May 2008 06:25:50 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 0963348059D; Sat, 10 May 2008 01:25:49 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzRZ-RTRMT1p; Sat, 10 May 2008 01:25:48 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 9AFBD480594; Sat, 10 May 2008 01:25:48 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id D745E19EC0BA; Sat, 10 May 2008 01:25:46 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JuSba-0006rY-Ow; Sat, 10 May 2008 01:25:46 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org, ietf@augustcellars.com, pgut001@cs.auckland.ac.nz, trevorf@EXCHANGE.MICROSOFT.com Subject: RE: weak authentication issue with rfc5083 In-Reply-To: <14c501c8afaf$899e2700$9cda7500$@com> Message-Id: Date: Sat, 10 May 2008 01:25:46 +1200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Jim Schaad" writes: >I believe you have misunderstood the issue that Trevor raised. > >His problem is: > >1. I send you and him a single Authenticated Message. > >2. He takes the common CEK in the original message, uses it to create a MAC >on an new message and then sends it on to you. > >As is always true with Authenticated messages, there is no proof of origin. >He worries that you might be confused and believe the second messages was >from me rather than from him. Since they both use the same CEK that is not a >factor that could be used to distinguish them. Ah, OK, thanks. How serious a threat is this in practice though? Wouldn't people just use asymmetric auth if they're worried about proof of origin? I realise it's kind of an interesting problem to solve, but does it need solving beyond a security considerations note "If you're seriously worried about proof of origin use a signature"? Peter. From owner-ietf-smime@mail.imc.org Fri May 9 07:43:50 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 02B7A3A67FA for ; Fri, 9 May 2008 07:43:50 -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=[AWL=0.001, 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 x+PolJ7e1NFK for ; Fri, 9 May 2008 07:43:49 -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 B26553A67CE for ; Fri, 9 May 2008 07:43:48 -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 m49EOVHB034135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 May 2008 07:24: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 m49EOVBw034134; Fri, 9 May 2008 07:24: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 cx295.800onemail.com (cx295.800onemail.com [209.171.54.152]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m49EOT03034102 for ; Fri, 9 May 2008 07:24:30 -0700 (MST) (envelope-from dbrown@certicom.com) Received: from ex13-n02.exchserver.com ([192.168.162.157]) by cx295.800onemail.com (8.13.1/8.13.1) with ESMTP id m49ELmJx026372; Fri, 9 May 2008 10:21:54 -0400 Received: from EX40.exchserver.com ([192.168.162.205]) by ex13-n02.exchserver.com ([192.168.162.161]) with mapi; Fri, 9 May 2008 10:18:49 -0400 From: Daniel Brown To: Peter Gutmann , "ietf-smime@imc.org" , "ietf@augustcellars.com" , "trevorf@EXCHANGE.MICROSOFT.com" Date: Fri, 9 May 2008 10:21:43 -0400 Subject: RE: weak authentication issue with rfc5083 Thread-Topic: weak authentication issue with rfc5083 Thread-Index: Acix2wfjBUv/oBsBQqurc4yjn91w8QAAeqSw Message-ID: References: <14c501c8afaf$899e2700$9cda7500$@com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CRXEFW-Info: Please contact Ceryx for more information X-CRXEFW-Virus: Clean X-CRXEFW-From: dbrown@certicom.com Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter, Jim, This is a serious problem, imo. If Bob receives an AuthenticatedData from = Alice but it is not really from Alice, then there really is no authenticati= on, despite the promise that AuthenticatedData provides authentication. Wh= at security service is AuthenticatedData providing in this case? If the Ch= arles is the attacker, then cannot Charles strip off his RecipientInfo from= the AuthenticatedData, in which case, Bob has no way of knowing that Alice= originallly sent the AuthenticatedData to two parties? A difference between SignedData and AuthenticatedData is that with the latt= er Bob cannot prove (cryptographically) to others that Alice authenticated = anything. That's the motivation to use AuthenticatedData instead of Signed= Data. *** Maybe AuthEnvData is a little different from AuthData, though. For example= , if the key management mechanism is key transport, so Alice provides no ce= rtificate, then effectively Alice is anonymous. In that case, the MAC only= protects integrity of the message from modification in transit, it does no= t provide authentication. (Cf. TLS with unauthenticated clients, where rec= ords are MAC for a similar purpose.) If AuthEnvData is used for that lesse= r purpose, then the substitutuion attack by Charles is not as significant, = because Alice is essentially anonymous. From reading 5083, I interpret its intent only to be add integrity to EnvDa= ta, since CBC mode does not provide full integrity. However, for some choi= ces of key management, it has the further capability of authenticating the = sender (i.e. if the key management authenticates the sender, which in does = in all cases except key transport). This is a useful capability and should= be noted. Regardless, it should be emphasized that, at least in the case = of key transport, that no actual authentication is provided (just integrity= ). Otherwise, evidently there is a risk of misinterpretation. Best regards, Dan -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Peter Gutmann Sent: Friday, May 09, 2008 9:26 AM To: ietf-smime@imc.org; ietf@augustcellars.com; pgut001@cs.auckland.ac.nz; = trevorf@EXCHANGE.MICROSOFT.com Subject: RE: weak authentication issue with rfc5083 "Jim Schaad" writes: >I believe you have misunderstood the issue that Trevor raised. > >His problem is: > >1. I send you and him a single Authenticated Message. > >2. He takes the common CEK in the original message, uses it to create a MA= C >on an new message and then sends it on to you. > >As is always true with Authenticated messages, there is no proof of origin= . >He worries that you might be confused and believe the second messages was >from me rather than from him. Since they both use the same CEK that is no= t a >factor that could be used to distinguish them. Ah, OK, thanks. How serious a threat is this in practice though? Wouldn't people just use asymmetric auth if they're worried about proof of origin? = I realise it's kind of an interesting problem to solve, but does it need solv= ing beyond a security considerations note "If you're seriously worried about pr= oof of origin use a signature"? Peter. From owner-ietf-smime@mail.imc.org Fri May 9 13:12: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 C22573A68B7 for ; Fri, 9 May 2008 13:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, 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 fpjW12GbFnzX for ; Fri, 9 May 2008 13:12:27 -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 8EB223A67CE for ; Fri, 9 May 2008 13:10:41 -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 m49JrUK5058907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 May 2008 12:53:30 -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 m49JrUce058906; Fri, 9 May 2008 12:53:30 -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.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.1.17]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m49JrSN8058899 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Fri, 9 May 2008 12:53:29 -0700 (MST) (envelope-from trevorf@exchange.microsoft.com) Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) by DF-GWY-05.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 9 May 2008 12:54:17 -0700 Received: from df-mlt-02.exchange.corp.microsoft.com (157.54.94.20) by df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 9 May 2008 12:54:16 -0700 Received: from DF-MBX-61.exchange.corp.microsoft.com ([157.54.109.22]) by DF-MLT-02.exchange.corp.microsoft.com ([157.54.94.20]) with mapi; Fri, 9 May 2008 12:53:52 -0700 From: Trevor Freeman To: pgut001 , "ietf-smime@imc.org" , "ietf@augustcellars.com" Date: Fri, 9 May 2008 19:53:02 +0000 Subject: RE: weak authentication issue with rfc5083 Thread-Topic: weak authentication issue with rfc5083 Thread-Index: Aciu6YBkwNV9yBxhQNWEO1d1mLywFgAab23AAKFFZGEADQtFEA== Message-ID: References: <14c501c8afaf$899e2700$9cda7500$@com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Peter, The push back to why doesn't everyone just use signatures is when I have an= existing security mechanism like Kerberos which builds secure pair wise ke= ys. Kerberos shared secrets can establish mutual authentication providing b= oth parties demonstrate knowledge of the shared secret. I don't think the s= olution is that complex. If I encrypt the MAC with the pair wise secret I a= chieve mutual authentication. We use the same mechanism to learn the CEK, w= e just need to do the same again to prove I know both the KEK and the MAC. Trevor -----Original Message----- From: pgut001 [mailto:pgut001@cs.auckland.ac.nz] Sent: Friday, May 09, 2008 6:26 AM To: ietf-smime@imc.org; ietf@augustcellars.com; pgut001@cs.aucKland.ac.nz; = Trevor Freeman Subject: RE: weak authentication issue with rfc5083 "Jim Schaad" writes: >I believe you have misunderstood the issue that Trevor raised. > >His problem is: > >1. I send you and him a single Authenticated Message. > >2. He takes the common CEK in the original message, uses it to create a MA= C >on an new message and then sends it on to you. > >As is always true with Authenticated messages, there is no proof of origin= . >He worries that you might be confused and believe the second messages was >from me rather than from him. Since they both use the same CEK that is no= t a >factor that could be used to distinguish them. Ah, OK, thanks. How serious a threat is this in practice though? Wouldn't people just use asymmetric auth if they're worried about proof of origin? = I realise it's kind of an interesting problem to solve, but does it need solv= ing beyond a security considerations note "If you're seriously worried about pr= oof of origin use a signature"? Peter. From owner-ietf-smime@mail.imc.org Fri May 9 14:05:25 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 44CA83A6801 for ; Fri, 9 May 2008 14:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=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 RYbkrj9H-28s for ; Fri, 9 May 2008 14:05:24 -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 597743A67EC for ; Fri, 9 May 2008 14:05:23 -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 m49KhES1068268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 May 2008 13:43: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 m49KhEBk068265; Fri, 9 May 2008 13:43: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 woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m49KhBYk068243 for ; Fri, 9 May 2008 13:43:12 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200805092043.m49KhBYk068243@balder-227.proper.com> Received: (qmail 9843 invoked by uid 0); 9 May 2008 20:43:05 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.129.167) by woodstock.binhost.com with SMTP; 9 May 2008 20:43:05 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 09 May 2008 14:11:21 -0400 To: "Turner, Sean P." , "'Tony Capel'" , "'Paul Hoffman'" , From: Russ Housley Subject: RE: S/MIME v3.2 IDs key size text In-Reply-To: <025e01c8af97$73f5a4e0$0201a8c0@Wylie> References: <023701c8aef2$ad31a650$0201a8c0@Wylie> <004301c8aef7$bcafeba0$02b5a8c0@tony> <025e01c8af97$73f5a4e0$0201a8c0@Wylie> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Are you saying that I MAY NOT support keys bigger than 4096? At 12:37 PM 5/6/2008, Turner, Sean P. wrote: > 0 < key size < 511 : MUST NOT > 512 < key size < 1023 : SHOULD- >1024 < key size < 2048 : MUST >2049 < key size < 4096 : MAY From owner-ietf-smime@mail.imc.org Fri May 9 14:57:18 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 83A583A68B6 for ; Fri, 9 May 2008 14:57:18 -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 18O3rg9MTtaB for ; Fri, 9 May 2008 14:57:17 -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 4A4203A67A8 for ; Fri, 9 May 2008 14:57:17 -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 m49LeNot084146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 May 2008 14:40: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 m49LeN63084144; Fri, 9 May 2008 14:40: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 [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 m49LeKQm084116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 May 2008 14:40:21 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <025e01c8af97$73f5a4e0$0201a8c0@Wylie> References: <023701c8aef2$ad31a650$0201a8c0@Wylie> <004301c8aef7$bcafeba0$02b5a8c0@tony> <025e01c8af97$73f5a4e0$0201a8c0@Wylie> Date: Fri, 9 May 2008 14:40:17 -0700 To: "Turner, Sean P." , From: Paul Hoffman Subject: RE: S/MIME v3.2 IDs key size text Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:37 PM -0400 5/6/08, Turner, Sean P. wrote: >Just a thought ... since we've now got a way to indicate + and - with >requirements should we apply it the key sizes in 3850bis? That way people >will have a hint that in the next update the shorter keys will likely become >not so welcome and large keys more so? > > 0 < key size < 511 : MUST NOT > 512 < key size < 1023 : SHOULD- >1024 < key size < 2048 : MUST >2049 < key size < 4096 : MAY Beyond what Russ just pointed out, I find the first line to be in bad taste. Any IETF spec that says "you must not be able to verify a signature even though it is valid" is pretty offensive. Can we return to talking about interoperability? From owner-ietf-smime@mail.imc.org Fri May 9 17:42:47 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 D04A73A683D for ; Fri, 9 May 2008 17:42:47 -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 QdIbAIeuU2Yv for ; Fri, 9 May 2008 17:42:46 -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 82E9B3A67A8 for ; Fri, 9 May 2008 17:42:46 -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 m4A0ClFD049166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 May 2008 17:12: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 m4A0Cl1K049165; Fri, 9 May 2008 17:12: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 ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4A0Cjdr049144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 May 2008 17:12:46 -0700 (MST) (envelope-from blake@sendmail.com) Received: from fife.sendmail.com (fife.sendmail.com [209.246.26.50]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id m4A0Fd2C024470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 May 2008 17:15:40 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1210378540; bh=zWcwQk26qycMHwi7DfOWsWP2PTVm8sb+GhPc u2b6m+k=; h=Received:X-DKIM:DKIM-Signature:Date:From:To:Cc:Subject: Message-ID:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent:X-MM-Ex-RefId; b=N06dvm Iftu5CdrR2aazsKH9glp1w+1zFfOrgaozB8rIYkv/q7DR9nA9kWbkmD7LSSMEcFEC9n CT5tJIVMCi/dNxupa1qiuuE/4XXGj+jTvtzPedCqSZV2SnqErDQjgLB0CeNpND/lQPg VtP3w4Fq6c3SIfeqTPgJL48w+WF4kDI= Received: from dell-desktop.example.com (cpe-071-077-208-015.ec.res.rr.com [71.77.208.15]) (authenticated bits=0) by fife.sendmail.com (Switch-3.3.1/Switch-3.3.2mp) with ESMTP id m4A0CbZs017710 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 9 May 2008 17:12:42 -0700 X-DKIM: Sendmail DKIM Filter v2.2.3 fife.sendmail.com m4A0CbZs017710 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=fife.dkim; t=1210378363; bh=zWcwQk26qycMHwi7DfOWsWP2PTVm8sb+GhPcu 2b6m+k=; h=Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To: User-Agent:X-MM-Ex-RefId; b=sP/9dowMONzfAAmVPymL4enNbH/PvxAQz+cfPH EuzoxQjx4I0e6WjxNZZ8nrOtgGCVVhphJWSBppEblZUlAVhb8fpRRrcutYJ7UsnrtMt NU3tyhlFmJ5tV92kVIbohWWP11e+qDWj9Wg0cTv06F+PKH2X4SbOrq4pZ1PakfcBIA= Date: Fri, 9 May 2008 17:12:39 -0700 From: Blake Ramsdell To: Paul Hoffman Cc: "Turner, Sean P." , ietf-smime@imc.org Subject: Re: S/MIME v3.2 IDs key size text Message-ID: <20080510001238.GA13646@dell-desktop.example.com> References: <023701c8aef2$ad31a650$0201a8c0@Wylie> <004301c8aef7$bcafeba0$02b5a8c0@tony> <025e01c8af97$73f5a4e0$0201a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-MM-Ex-RefId: 149371::080509171243-0FBC0B90-13FD2C6A/0-0/0-1 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, May 09, 2008 at 02:40:17PM -0700, Paul Hoffman wrote: > Beyond what Russ just pointed out, I find the first line to be in bad > taste. Any IETF spec that says "you must not be able to verify a signature > even though it is valid" is pretty offensive. > > Can we return to talking about interoperability? I think you and I are on the same page, and there's two things: 1. Interoperability. The key sizes to guarantee two implementations will talk to each other. 2. Security considerations. The key sizes that are a no-no due to insufficient or overly-sufficient size. Have we given up on the separation of these? Blake From owner-ietf-smime@mail.imc.org Fri May 9 18:30: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 A2AF13A67E5 for ; Fri, 9 May 2008 18:30:13 -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 L1CZ7LBRcnmu for ; Fri, 9 May 2008 18:30:12 -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 77FE43A67A8 for ; Fri, 9 May 2008 18:30: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 m4A1EJZX076560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 May 2008 18:14:19 -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 m4A1EJRn076559; Fri, 9 May 2008 18:14:19 -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 m4A1ECms076505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 May 2008 18:14:14 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20080510001238.GA13646@dell-desktop.example.com> References: <023701c8aef2$ad31a650$0201a8c0@Wylie> <004301c8aef7$bcafeba0$02b5a8c0@tony> <025e01c8af97$73f5a4e0$0201a8c0@Wylie> <20080510001238.GA13646@dell-desktop.example.com> Date: Fri, 9 May 2008 18:14:10 -0700 To: Blake Ramsdell From: Paul Hoffman Subject: Re: S/MIME v3.2 IDs key size text Cc: "Turner, Sean P." , ietf-smime@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 5:12 PM -0700 5/9/08, Blake Ramsdell wrote: >On Fri, May 09, 2008 at 02:40:17PM -0700, Paul Hoffman wrote: >> Beyond what Russ just pointed out, I find the first line to be in bad >> taste. Any IETF spec that says "you must not be able to verify a signature >> even though it is valid" is pretty offensive. >> >> Can we return to talking about interoperability? > >I think you and I are on the same page, and there's two things: > >1. Interoperability. The key sizes to guarantee two implementations will talk > to each other. > >2. Security considerations. The key sizes that are a no-no due to insufficient > or overly-sufficient size. > >Have we given up on the separation of these? For interoperability, the receiver MUST be able to verify all sizes that the signer MUST be able to sign. For security, the signer MUST be able to sign using keys of at least a certain size. A receiver should expect that some of the signatures it wants to verify will be bigger than the one size in the spec because a receiver cannot accurately predict the security decisions of all the senders with which it interacts. I propose that that size is 1024 bits: that's plenty of strength for most typical non-paranoid applications for at least five years. If it turns out to be too short due to an unexpected large reduction in strength of RSA, we can revise then. Quite frankly, in that case, we might be recommending ECDSA anyhow. From owner-ietf-smime@mail.imc.org Sat May 10 01:38:52 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 E49D93A67A1 for ; Sat, 10 May 2008 01:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 BmI9p58KQxB2 for ; Sat, 10 May 2008 01:38: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 B39D73A65A5 for ; Sat, 10 May 2008 01:38: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 m4A8Hldp045019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 May 2008 01:17: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 m4A8HlJm045018; Sat, 10 May 2008 01:17: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 mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4A8HfH6044961; Sat, 10 May 2008 01:17:47 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id B22C618403; Sat, 10 May 2008 19:45:08 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUoLM2QmDnua; Sat, 10 May 2008 19:45:08 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 946AF183FF; Sat, 10 May 2008 19:45:01 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 4F6B119EC0BA; Sat, 10 May 2008 19:45:00 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JujlM-0003UN-5H; Sat, 10 May 2008 19:45:00 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org, phoffman@imc.org, turners@ieca.com Subject: RE: S/MIME v3.2 IDs key size text In-Reply-To: Message-Id: Date: Sat, 10 May 2008 19:45:00 +1200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul Hoffman writes: >At 12:37 PM -0400 5/6/08, Turner, Sean P. wrote: >> 0 < key size < 511 : MUST NOT >> 512 < key size < 1023 : SHOULD- >>1024 < key size < 2048 : MUST >>2049 < key size < 4096 : MAY > >Beyond what Russ just pointed out, I find the first line to be in bad taste. >Any IETF spec that says "you must not be able to verify a signature even >though it is valid" is pretty offensive. So an implementation is supposed to do what, tell the user that they can be absolutely totally assured that the signature is valid, all 12 bits of it? I guess it'll save implementation time because you can just report "signature might be valid" without even having to verify it. Peter. From owner-ietf-smime@mail.imc.org Sat May 10 15:50: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 7C6FA3A67D8 for ; Sat, 10 May 2008 15:50:05 -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 Ii3OPojhBzu7 for ; Sat, 10 May 2008 15:50:04 -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 644793A67A7 for ; Sat, 10 May 2008 15:50:03 -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 m4AMNYpR025026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 May 2008 15:23:34 -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 m4AMNY8k025023; Sat, 10 May 2008 15:23:34 -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 m4AMN9so024877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 May 2008 15:23:11 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sat, 10 May 2008 15:23:07 -0700 To: pgut001@cs.auckland.ac.nz (Peter Gutmann), ietf-smime@imc.org, turners@ieca.com From: Paul Hoffman Subject: RE: S/MIME v3.2 IDs key size text Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 7:45 PM +1200 5/10/08, Peter Gutmann wrote: >Paul Hoffman writes: >>At 12:37 PM -0400 5/6/08, Turner, Sean P. wrote: >>> 0 < key size < 511 : MUST NOT >>> 512 < key size < 1023 : SHOULD- >>>1024 < key size < 2048 : MUST >>>2049 < key size < 4096 : MAY >> >>Beyond what Russ just pointed out, I find the first line to be in bad taste. >>Any IETF spec that says "you must not be able to verify a signature even >>though it is valid" is pretty offensive. > >So an implementation is supposed to do what, tell the user that they can be >absolutely totally assured that the signature is valid, all 12 bits of it? Yes. Why not? If you don't want to fully comply with the standard for any of a variety of reasons, by all means don't. From owner-ietf-smime@mail.imc.org Mon May 12 06:57: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 40E993A695E for ; Mon, 12 May 2008 06:57:55 -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 c9RiZ6jtvlWT for ; Mon, 12 May 2008 06:57:54 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 8A0D83A6884 for ; Mon, 12 May 2008 06:57: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 m4CDW8MC063216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 06:32: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 m4CDW8fk063215; Mon, 12 May 2008 06:32: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 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 m4CDW64W063201; Mon, 12 May 2008 06:32:07 -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 m4CDW5Nm004736; Mon, 12 May 2008 09:32:06 -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 m4CDW5Ai004728; Mon, 12 May 2008 09:32:05 -0400 Received: from m5922fa48.tmodns.net ([172.31.11.160]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 May 2008 09:32:02 -0400 Cc: "Turner, Sean P." , Message-Id: From: Timothy J Miller To: Paul Hoffman In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-5-363644505; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: S/MIME v3.2 IDs key size text Date: Mon, 12 May 2008 08:31:18 -0500 References: <023701c8aef2$ad31a650$0201a8c0@Wylie> <004301c8aef7$bcafeba0$02b5a8c0@tony> <025e01c8af97$73f5a4e0$0201a8c0@Wylie> X-Mailer: Apple Mail (2.919.2) X-OriginalArrivalTime: 12 May 2008 13:32:04.0048 (UTC) FILETIME=[90C97500:01C8B434] Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-5-363644505 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On May 9, 2008, at 4:40 PM, Paul Hoffman wrote: > > At 12:37 PM -0400 5/6/08, Turner, Sean P. wrote: >> >> 0 < key size < 511 : MUST NOT >> 512 < key size < 1023 : SHOULD- > Beyond what Russ just pointed out, I find the first line to be in > bad taste. Any IETF spec that says "you must not be able to verify a > signature even though it is valid" is pretty offensive. How about adding a "MUST warn the user that key is too damn short to be considered safe, even though the signature is valid" clause instead? -- Tim --Apple-Mail-5-363644505 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 AUcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwNTEyMTMzMTE4 WjAjBgkqhkiG9w0BCQQxFgQUxfk3lP26BF3SYLr1LRwVGQO/fiEwcgYJKwYBBAGCNxAEMWUwYzBd MRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUG A1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIGmjB0BgsqhkiG9w0BCRACCzFl oGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowDQYJKoZIhvcNAQEB BQAEgYBHUGdy3028S+XL94tRF7Tyw3kPdLmx1v8WVGCJl4kkgZ1E5cno8epj/UDK+jvLpdRXRw52 V5yJ1WRzaiVDWMv1Ysyj0ZhvbDnVQ0CFLt5MbrrHT+PC0or1TvvNq4gV3ZnLyQH2cZY0MMnSdgXh HTIPlCTRnSMDv0suVPh6sT0/ewAAAAAAAA== --Apple-Mail-5-363644505-- From owner-ietf-smime@mail.imc.org Mon May 12 07:31:11 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 B52273A67B6 for ; Mon, 12 May 2008 07:31:11 -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 3-q4QfFh5AWB for ; Mon, 12 May 2008 07:31:11 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 01D853A6B8F for ; Mon, 12 May 2008 07:31: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 m4CE3G8a075098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 07:03:16 -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 m4CE3G5M075096; Mon, 12 May 2008 07:03:16 -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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m4CE3EuC075056 for ; Mon, 12 May 2008 07:03:14 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 7764 invoked from network); 12 May 2008 13:53:41 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;12 May 2008 13:53:41 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 12 May 2008 13:53:41 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: S/MIME v3.2 IDs key size text Date: Mon, 12 May 2008 10:03:10 -0400 Message-ID: in-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: S/MIME v3.2 IDs key size text Thread-Index: Aci0NwFQ77XqvYMvQnyonoenqEXKIwAAEz4g References: <023701c8aef2$ad31a650$0201a8c0@Wylie> <004301c8aef7$bcafeba0$02b5a8c0@tony> <025e01c8af97$73f5a4e0$0201a8c0@Wylie> From: "Carl Wallace" To: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > How about adding a "MUST warn the user that key is too damn short to be considered safe, even though the=20 > signature is valid" clause instead? >=20 > -- Tim This isn't sufficient for verification of archived email. A weak signature may be covered by a timestamp that enables its verification. This problem should be addressed using something like DSSC. =20 From owner-ietf-smime@mail.imc.org Mon May 12 07:43: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 A96C93A683F for ; Mon, 12 May 2008 07:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.248 X-Spam-Level: X-Spam-Status: No, score=-4.248 tagged_above=-999 required=5 tests=[AWL=-2.202, 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 U38VINixc1cd for ; Mon, 12 May 2008 07:43:44 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id DD09E3A67AC for ; Mon, 12 May 2008 07:43: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 m4CEHfUg080838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 07:17:41 -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 m4CEHf47080837; Mon, 12 May 2008 07:17:41 -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 mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4CEHdM6080784 for ; Mon, 12 May 2008 07:17:40 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 3022E185D9; Tue, 13 May 2008 02:17:35 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1t8m97zYr5x; Tue, 13 May 2008 02:17:35 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C477718617; Tue, 13 May 2008 02:17:33 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id D0DAD19EC0BA; Tue, 13 May 2008 02:17:29 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JvYqH-0007Vu-Mu; Tue, 13 May 2008 02:17:29 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: dbrown@certicom.com, ietf-smime@imc.org, ietf@augustcellars.com, pgut001@cs.auckland.ac.nz, trevorf@EXCHANGE.MICROSOFT.com Subject: RE: weak authentication issue with rfc5083 In-Reply-To: Message-Id: Date: Tue, 13 May 2008 02:17:29 +1200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Daniel Brown writes: >This is a serious problem, imo. If Bob receives an AuthenticatedData from >Alice but it is not really from Alice, then there really is no >authentication, despite the promise that AuthenticatedData provides >authentication. What security service is AuthenticatedData providing in this >case? Maybe it would have been better to call it IntegrityProtectedData :-). That's actually the only thing I've ever used it for, my assumption was that you sign email and you MAC stored data. Peter. From owner-ietf-smime@mail.imc.org Mon May 12 08:24:24 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 C2CCC3A67FB for ; Mon, 12 May 2008 08:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=-0.276, 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 QKaPTTB07foi for ; Mon, 12 May 2008 08:24:24 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 05F9F3A67EE for ; Mon, 12 May 2008 08:24:23 -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 m4CFAhxI001596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 08:10:43 -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 m4CFAhK4001591; Mon, 12 May 2008 08:10:43 -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 m4CFAGip001402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 08:10:17 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <023701c8aef2$ad31a650$0201a8c0@Wylie> <004301c8aef7$bcafeba0$02b5a8c0@tony> <025e01c8af97$73f5a4e0$0201a8c0@Wylie> Date: Mon, 12 May 2008 08:10:10 -0700 To: Timothy J Miller From: Paul Hoffman Subject: Re: S/MIME v3.2 IDs key size text Cc: "Turner, Sean P." , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 8:31 AM -0500 5/12/08, Timothy J Miller wrote: >On May 9, 2008, at 4:40 PM, Paul Hoffman wrote: >> >>At 12:37 PM -0400 5/6/08, Turner, Sean P. wrote: >>> >>> 0 < key size < 511 : MUST NOT >>>512 < key size < 1023 : SHOULD- > >>Beyond what Russ just pointed out, I find the first line to be in >>bad taste. Any IETF spec that says "you must not be able to verify >>a signature even though it is valid" is pretty offensive. > >How about adding a "MUST warn the user that key is too damn short to >be considered safe, even though the signature is valid" clause >instead? I seriously doubt we could get consensus on the number of bits for that to kick in. Also, this would prevent an automated signature validation system with no UI from being able to be conformant. We are not the security nannies of the Internet. As long as we give a reasonable number of bits that all implementations should be able to sign and verify in order to make reasonably-strong signatures, we should step back and let organizations make their own rules. From owner-ietf-smime@mail.imc.org Mon May 12 08:49: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 5650E3A6A7D for ; Mon, 12 May 2008 08:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.807 X-Spam-Level: X-Spam-Status: No, score=-3.807 tagged_above=-999 required=5 tests=[AWL=-1.761, 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 nw8+VJbD9BD9 for ; Mon, 12 May 2008 08:49: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 946A23A686C for ; Mon, 12 May 2008 08:49: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 m4CFWval008849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 08:32:57 -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 m4CFWvYh008848; Mon, 12 May 2008 08:32:57 -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 mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4CFWtAK008808; Mon, 12 May 2008 08:32:56 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 48F0818609; Tue, 13 May 2008 03:32:51 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-x-kaXEnLtz; Tue, 13 May 2008 03:32:51 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2B176185F4; Tue, 13 May 2008 03:32:51 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 2C4B719EC0BA; Tue, 13 May 2008 03:32:46 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1Jva18-0002rS-0p; Tue, 13 May 2008 03:32:46 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: phoffman@imc.org, tmiller@mitre.org Subject: Re: S/MIME v3.2 IDs key size text Cc: ietf-smime@imc.org, turners@ieca.com In-Reply-To: Message-Id: Date: Tue, 13 May 2008 03:32:46 +1200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul Hoffman writes: >We are not the security nannies of the Internet. As long as we give a >reasonable number of bits that all implementations should be able to sign and >verify in order to make reasonably-strong signatures, we should step back and >let organizations make their own rules. No, that's exactly what we shouldn't do, because then organisations will use the fact that the standard doesn't set a sane limit on the key size to justify using completely stupid key sizes (or as a generalisation completely insecure "security" practices) [0]. I realise that it's not possible to explicitly outlaw every kind of stupid behaviour that users will engage in, but since there's a list of key sizes in the doc anyway it's a pretty trivial change to add a sensible lower bound to it. Peter. [0] The best one I've ever heard in this area was a government department that said that while a NIST standard required the use of security technology X, it didn't say it had to be *effectively* applied, merely applied (imagine the computer equivalent of "doors must be fitted with Medeco locks", but since the standard never said you have to actually lock the doors, merely that they had to be there, it was fine to leave all the doors unlocked). That's an extreme case, but it's merely the tip of the iceberg of lesser stupidity that organisations will engage in because a standard doesn't say they can't. From owner-ietf-smime@mail.imc.org Mon May 12 09:13: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 016E33A6872 for ; Mon, 12 May 2008 09:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[AWL=-1.597, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, MIME_BASE64_BLANKS=0.041] 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 WKrtsPB+arVq for ; Mon, 12 May 2008 09:13:31 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 2D2293A67EE for ; Mon, 12 May 2008 09:13:31 -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 m4CFxgDl016897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 08:59:42 -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 m4CFxgoo016896; Mon, 12 May 2008 08:59:42 -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 (mail.tor.primus.ca [216.254.136.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4CFxf59016866; Mon, 12 May 2008 08:59:41 -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 1JvaRA-00021p-1K; Mon, 12 May 2008 11:59:40 -0400 From: "Tony Capel" To: "'Turner, Sean P.'" Cc: , "'Paul Hoffman'" , "'Timothy J Miller'" Subject: RE: S/MIME v3.2 IDs key size text Date: Mon, 12 May 2008 11:59:32 -0400 Message-ID: <003501c8b449$2b88d860$02b5a8c0@tony> MIME-Version: 1.0 Content-Type: application/pkcs7-mime; smime-type=signed-data; name="smime.p7m" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7m" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6838 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: thread-index: Aci0NleKTUV18uyISbCzl6pNQOuo+QACQnEw Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEU0NvbnRl bnQtVHlwZTogdGV4dC9wbGFpbjsNCgljaGFyc2V0PSJ1cy1hc2NpaSINCkNvbnRlbnQtVHJhbnNm ZXItRW5jb2Rpbmc6IDdiaXQNCg0KBIIQolNlYW4gZXQgYWw6DQoNCkhvdyBhYm91dDoNCg0KICAg MCA8ICBrZXkgc2l6ZSA8IDUxMiAgICAgOiBNQVkgICAgIGJ1dCByZWZlciB0byBzZWN1cml0eSBj b25zaWRlcmF0aW9ucw0Kc2VjdGlvbg0KIDUxMiA8PSBrZXkgc2l6ZSA8IDEwMjQgICAgOiBTSE9V TEQtIGJ1dCByZWZlciB0byBzZWN1cml0eSBjb25zaWRlcmF0aW9ucw0Kc2VjdGlvbg0KMTAyNCA8 PSBrZXkgc2l6ZSA8PSAyMDQ4ICAgOiBNVVNUDQoyMDQ4IDwgIGtleSBzaXplICAgICAgICAgICA6 IE1BWSAgICAgYnV0IHJlZmVyIHRvIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zDQpzZWN0aW9uDQoN CkZvciBsYXJnZXIga2V5cywgc29tZSB0ZXh0IGZvciB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlv bnMgc2VjdGlvbiBtaWdodA0KYmUgYWRkZWQsIGUuZy4gc29tZXRoaW5nIGxpa2U6DQoNCiJBIGRl bmlhbCBvZiBzZXJ2aWNlIG9wcG9ydHVuaXR5IG1heSBleHBsb2l0YWJsZSBieSBhdHRhY2tlcnMg d2hvIHByb3ZpZGUNCmFuIGV4Y2Vzc2l2ZWx5IGxhcmdlIGtleSwgb3IgYSBrZXkgc2VsZWN0ZWQg dG8gcmVxdWlyZSBleGNlc3NpdmUNCmNyeXB0b2dyYXBoaWMgcHJvY2Vzc2luZy4gIE9uZSBtaXRp Z2F0aW9uIGFwcHJvYWNoIHdvdWxkIHJlcXVpcmUgdGhhdCB0aGUNCmNvcnJlc3BvbmRpbmcgcHVi bGljIGtleSBjZXJ0aWZpY2F0ZSBiZSB2YWxpZGF0ZWQgdG8gYSB0cnVzdGVkIHJvb3QgW3RydXN0 DQphbmNob3JdIHByaW9yIHRvIHVzZSwgdGh1cyBlbnN1cmluZyB0aGF0IG9ubHkgdHJ1c3RlZCBw dWJsaWMga2V5cyBhcmUNCnVzZWQuICBIb3dldmVyLCBzb21lIGltcGxlbWVudGF0aW9ucyBtYXkg Y2hvb3NlIHRvIHBlcmZvcm0gc2lnbmF0dXJlDQp2ZXJpZmljYXRpb24gKG9yIGRhdGEgZW5jcnlw dGlvbikgaW4gcGFyYWxsZWwgd2l0aCBjZXJ0aWZpY2F0ZSB2YWxpZGF0aW9uLA0Kb3IgZXZlbiBp ZiBjZXJ0aWZpY2F0ZSB2YWxpZGF0aW9uIGZhaWxzLiAgSW4gc3VjaCBjYXNlcywgbWVhc3VyZXMg c2hvdWxkDQpiZSBpbmNsdWRlZCB0byBsaW1pdCB0aGUgaW1wYWN0LCBmb3IgZXhhbXBsZSBieSBs aW1pdGluZyBjcnlwdG9ncmFwaGljDQpwcm9jZXNzaW5nIHRpbWUgb3IgcmVxdWlyaW5nIGNlcnRp ZmljYXRlIHZhbGlkYXRpb24gcHJpb3IgdG8gdGhlIHVzZSBvZg0KbGFyZ2Uga2V5cy4iDQoNCkZv ciBzbWFsbGVyIGtleXMsIHRoaXMgaXMgYWxyZWFkeSBhZGRyZXNzZWQgdG8gc29tZSBleHRlbnQg Zm9yIGVuY3J5cHRpb24NCmluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLCBt YXliZSB0aGlzIG5lZWRzIHVwZGF0aW5nIGJhc2VkIG9uDQpvdXIgZXhwZXJpZW5jZSB3aXRoIHNt aW1lOg0KDQpDdXJyZW50IHRleHQ6DQoNCiAgIDQwLWJpdCBlbmNyeXB0aW9uIGlzIGNvbnNpZGVy ZWQgd2VhayBieSBtb3N0IGNyeXB0b2dyYXBoZXJzLiBVc2luZw0KICAgd2VhayBjcnlwdG9ncmFw aHkgaW4gUy9NSU1FIG9mZmVycyBsaXR0bGUgYWN0dWFsIHNlY3VyaXR5IG92ZXINCiAgIHNlbmRp bmcgcGxhaW50ZXh0LiAgSG93ZXZlciwgb3RoZXIgZmVhdHVyZXMgb2YgUy9NSU1FLCBzdWNoIGFz IHRoZQ0KICAgc3BlY2lmaWNhdGlvbiBvZiB0cmlwbGVERVMgYW5kIHRoZSBhYmlsaXR5IHRvIGFu bm91bmNlIHN0cm9uZ2VyDQogICBjcnlwdG9ncmFwaGljIGNhcGFiaWxpdGllcyB0byBwYXJ0aWVz IHdpdGggd2hvbSB5b3UgY29tbXVuaWNhdGUsDQogICBhbGxvdyBzZW5kZXJzIHRvIGNyZWF0ZSBt ZXNzYWdlcyB0aGF0IHVzZSBzdHJvbmcgZW5jcnlwdGlvbi4gIFVzaW5nDQogICB3ZWFrIGNyeXB0 b2dyYXBoeSBpcyBuZXZlciByZWNvbW1lbmRlZCB1bmxlc3MgdGhlIG9ubHkgYWx0ZXJuYXRpdmUg aXMNCiAgIG5vIGNyeXB0b2dyYXBoeS4gIFdoZW4gZmVhc2libGUsIHNlbmRpbmcgYW5kIHJlY2Vp dmluZyBhZ2VudHMgU0hPVUxEDQogICBpbmZvcm0gc2VuZGVycyBhbmQgcmVjaXBpZW50cyBvZiB0 aGUgcmVsYXRpdmUgY3J5cHRvZ3JhcGhpYyBzdHJlbmd0aA0KICAgb2YgbWVzc2FnZXMuDQoNClBy b3Bvc2VkIERyYWZ0IHRleHQ6DQoNCiJVc2luZyB3ZWFrIGNyeXB0b2dyYXBoeSBpbiBTL01JTUUg b2ZmZXJzIGxpdHRsZSBhY3R1YWwgc2VjdXJpdHkgb3Zlcg0Kc2VuZGluZyBwbGFpbnRleHQuDQpT b21lIGNyeXB0b2dyYXBoZXJzIGNvbnNpZGVyIHB1YmxpYyBrZXlzIG9mIGxlc3MgdGhhbiAxMDI0 KiBiaXRzIHRvIGJlDQp3ZWFrLCBhbG9uZyB3aXRoIHN5bW1ldHJpYyBlbmNyeXB0aW9uIGFsZ29y aXRobXMgb2YgbGVzcyB0aGFuIDY0IGJpdHMgYW5kDQpjZXJ0YWluIG9sZGVyIGhhc2ggYWxnb3Jp dGhtcyB1c2VkIGZvciBzaWduaW5nLg0KSW4gYW55IGdpdmVuIGFwcGxpY2F0aW9uLCBhbiBhcHBy b3ByaWF0ZSBhbmFseXNpcyBvZiB0aGUgdGhyZWF0cyBhbmQgcmlza3MNClNIT1VMRCBsZWFkIHRv IHRoZSBzZWxlY3Rpb24gb2YgYXBwcm9wcmlhdGUgYWxnb3JpdGhtcyBhbmQga2V5IHNpemVzLg0K Rm9yIHB1YmxpYyBrZXlzLCBhbGdvcml0aG1zIGFuZCBrZXkgc2l6ZXMgYXJlIG5vcm1hbGx5IGRl ZmluZWQgYnkgdGhlDQpwdWJsaWMga2V5IGlzc3VlciBpbiB0aGUgY29ycmVzcG9uZGluZyBjZXJ0 aWZpY2F0ZSwgYW5kIHRodXMgbm90IHVuZGVyIHRoZQ0KY29udHJvbCBvZiB0aGUgZW5kIHVzZXIu DQpGb3Igc3ltbWV0cmljIGVuY3J5cHRpb24gYW5kIGhhc2ggYWxnb3JpdGhtcywgUy9NSU1FIHN1 cHBvcnRzIHRoZSBhYmlsaXR5DQpvZiBwYXJ0aWVzIHRvIGNvbW11bmljYXRlIHRoZWlyIGNhcGFi aWxpdGllcyB0byBlYWNoIG90aGVyLCBhbGxvd2luZyB0aGUNCnVzZSBvZiBhcHByb3ByaWF0ZWx5 IHN0cm9uZyBtZWFzdXJlcy4NCldoZW4gZmVhc2libGUsIHNlbmRpbmcgYW5kIHJlY2VpdmluZyBh Z2VudHMgU0hPVUxEIGluZm9ybSBzZW5kZXJzIChwcmlvcg0KdG8gdHJhbnNtaXNzaW9uKSBhbmQg cmVjaXBpZW50cyBvZiB0aGUgcmVsYXRpdmUgY3J5cHRvZ3JhcGhpYyBzdHJlbmd0aCBvZg0KbWVz c2FnZXMgYW5kIFNIT1VMRCBwcm92aWRlIGEgd2FybmluZyBpZiB3ZWFrIGFsZ29yaXRobXMgb3Ig a2V5IHNpemVzIGFyZQ0KdXNlZC4NClN1Y2ggd2FybmluZ3MgYXJlIGVzcGVjaWFsbHkgaW1wb3J0 YW50IGlmIHRoZSBzeW1tZXRyaWMgZW5jcnlwdGlvbiBvciBoYXNoDQphbGdvcml0aG0gYXJlIHNp Z25pZmljYW50bHkgd2Vha2VyIHRoYW4gdGhlIGNvcnJlc3BvbmRpbmcgcHVibGljIGtleSwNCnNp bmNlIHRoaXMgd2lsbCByZXN1bHQgaW4gYSBtZXNzYWdlIHdpdGggd2Vha2VyIHNlY3VyaXR5IHRo YW4gdGhhdCBpbXBsaWVkDQpieSB0aGUgcHVibGljIGtleSBjZXJ0aWZpY2F0ZS4gIg0KDQoNCg0K VG9ueQ0KDQoqIG9mIGNvdXJzZSB0aGlzIGNvdWxkIGJlIGEgc21hbGxlciB2YWx1ZS4NCg0KfCAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KfCBGcm9tOiBvd25lci1pZXRmLXNtaW1lQG1haWwu aW1jLm9yZw0KfCBbbWFpbHRvOm93bmVyLWlldGYtc21pbWVAbWFpbC5pbWMub3JnXSBPbiBCZWhh bGYgT2YgVGltb3RoeSBKIE1pbGxlcg0KfCBTZW50OiBNYXkgMTIsIDIwMDggOTozMSBBTQ0KfCBU bzogUGF1bCBIb2ZmbWFuDQp8IENjOiBUdXJuZXIsIFNlYW4gUC47IGlldGYtc21pbWVAaW1jLm9y Zw0KfCBTdWJqZWN0OiBSZTogUy9NSU1FIHYzLjIgSURzIGtleSBzaXplIHRleHQNCnwNCnwNCnwN CnwgT24gTWF5IDksIDIwMDgsIGF0IDQ6NDAgUE0sIFBhdWwgSG9mZm1hbiB3cm90ZToNCnwgPg0K fCA+IEF0IDEyOjM3IFBNIC0wNDAwIDUvNi8wOCwgVHVybmVyLCBTZWFuIFAuIHdyb3RlOg0KfCA+ Pg0KfCA+PiAgIDAgPCBrZXkgc2l6ZSA8IDUxMSAgOiBNVVNUIE5PVA0KfCA+PiA1MTIgPCBrZXkg c2l6ZSA8IDEwMjMgOiBTSE9VTEQtDQp8DQp8ID4gQmV5b25kIHdoYXQgUnVzcyBqdXN0IHBvaW50 ZWQgb3V0LCBJIGZpbmQgdGhlIGZpcnN0IGxpbmUgdG8gYmUgaW4NCnwgPiBiYWQgdGFzdGUuIEFu eSBJRVRGIHNwZWMgdGhhdCBzYXlzICJ5b3UgbXVzdCBub3QgYmUgYWJsZSB0bw0KfCB2ZXJpZnkg YQ0KfCA+IHNpZ25hdHVyZSBldmVuIHRob3VnaCBpdCBpcyB2YWxpZCIgaXMgcHJldHR5IG9mZmVu c2l2ZS4NCnwNCnwgSG93IGFib3V0IGFkZGluZyBhICJNVVNUIHdhcm4gdGhlIHVzZXIgdGhhdCBr ZXkgaXMgdG9vIGRhbW4gc2hvcnQgdG8NCnwgYmUgY29uc2lkZXJlZCBzYWZlLCBldmVuIHRob3Vn aCB0aGUgc2lnbmF0dXJlIGlzIHZhbGlkIg0KfCBjbGF1c2UgaW5zdGVhZD8NCnwNCnwgLS0gVGlt DQp8DQp8DQoEAAAAAAAAAKCCClIwggTMMIIENaADAgECAhAcrp1rmvTmLyKKo9p0YWweMA0GCSqG SIb3DQEBBQUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UE CxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNTEw MjgwMDAwMDBaFw0xNTEwMjcyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDJ36zn 6vj4AxTEAJLVwX42wjzvfHIVy8CrjD0clc5vHhAsPwDtlybmtsfmrUMdP6SHR0dMPlT4bPjH/LGe vTBwvJexAwXqlfGtQMVEeksFovJg/Nc6ZWLv/xB7ola7xU5wLdaiHzztsELoXo1XIaymmdkR6dIa B8B0R0IL/MU06v3muiTRHQgVN6LXc88BQS9jsjo/vqUabvTJSls9laYVuzUCGfnU77yPDnF2WbtL tj7W/FoW9NYOifJJ/mwM7RXp2Yh1nHnOYCfdua11zi9zlXpAOoV1SbC432i8q80TgoURUKPgPAuu wApTzdcwb4UyRhvkSRDCbOKvH3n/27S1AgMBAAGjggGEMIIBgDASBgNVHRMBAf8ECDAGAQH/AgEA MEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWk IzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps 1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2Ex LmNybDCBgQYDVR0jBHoweKFjpGEwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5ghEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQUFAAOBgQCxL9mW4ZKi7oFg5cgqIPvh ZyzWAJhTowIb6ZBL+BhEnw9G9/qg/tMdGKPSvxzs1hmfSk1D+Mq7vhOASQXdIXMzV8JCWr76AJOy 5gQxkU5dPPBzBTdj67+DWZj9Zt7phjKakik8Oq5U2qYSUbGPyMrTR3jm26Uehwbj0RTAwiH2ujCC BX4wggRmoAMCAQICEESSWjobm8B74KlIfva/2j8wDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0 d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y cGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjAeFw0wODA0MTcwMDAwMDBa Fw0wOTA0MjAyMzU5NTlaMIIBFTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90 IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBT ZXJ2aWNlMRowGAYDVQQDFBFBLkMuIChUb255KSBDYXBlbDEgMB4GCSqGSIb3DQEJARYRY2FwZWxA Y29tZ2F0ZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtfsxOpz6QFfItcBlg xYSH9UbbQaogvaigfZAV45h+fnjVJ+n2zUA6XHOx7XwRZt8EgFcA4aSthXF3evO8DVqKBZcwwBcN 7ylVioSRlDD/TUvXScF+Uh77iC9+9cCN5+mWtNcf1rrBu3pLpViYObKS65JwxinyF9t2AhOLbkVZ hs7b9aKQHq6qAMvQhskxzfdr404pJUKVJ7gGoZOOv1uA3KQdKszXvkG5plO3eNNTaG74JyXTVuLE w/5/RDfaEtD3ayNSBozXWFoGkkD6qCMYtVYhbZFe1JFHU9eJT5Ps5cNmQ3qT43iM/96lqs81f8or ERTHMSvOt0gEJx02eRqZAgMBAAGjgf4wgfswCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG +EUBBxcDMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0P BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAwBgpghkgBhvhFAQYHBCIWIDcx NThjMjkzOGUyZDFkMGRkMTljMTA0MzAyN2QzYjFlMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9J bmRDMURpZ2l0YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDANBgkqhkiG 9w0BAQUFAAOCAQEApfrZkVZZ2pIl60wajeIbTEMslpmB3iHiD7joNe73Ipw+CWfhKKK/kmaSxSRH aKuIOsS2YMM4NHUQkdDA+/BRpBpVHEvdoghwsMh1RLmElt6iQcbnMCNVxvC/36F5loFfSp4TRTVJ GX+EH6It+F4faK88hEQXNNytqLQMHdgX6XSZlnj3M2BhhMUHkxNl7GPNHEkhOQK1J/x7bTx5YgoM pks8eKeO+tuM3GUYeGvy8SsOuWf+1hDaMotfIASiz1Y0z6CL/NImCFhOmMIO9R8z4HitRU5/MFsO lyxcGtxUbp+S9tDJ0bVCNhqvViIgnxCWJ8s4iguwImF4qviYNE9TCzGCBPQwggTwAgEBMIHyMIHd MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNV BAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEESSWjob m8B74KlIfva/2j8wCQYFKw4DAhoFAKCCAtYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDgwNTEyMTU1OTMyWjAjBgkqhkiG9w0BCQQxFgQUeaKpL9XJxQtPiF4g+1Rq OvNjazcwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAHBgUrDgMCGjAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwCgYIKoZIhvcNAgUwggED BgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNj cmliZXIgQ0EgLSBHMgIQRJJaOhubwHvgqUh+9r/aPzCCAQUGCyqGSIb3DQEJEAILMYH1oIHyMIHd MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNV BAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEESSWjob m8B74KlIfva/2j8wDQYJKoZIhvcNAQEBBQAEggEATBLKZ09eiUNYLCiSl1lzwobsz5JHVQhQY2zt Z9ekb3BaCbrWMCuzE098v1wtXPS4hrsLdCsTF46hy8wuu0uMsnT6Ev5XvDrEqqDXKM8ED3mEHbp9 X7tmqLFzecRdg1DD8kQMLll6iFvQxLCIAUQIMTmALC+xkxP2djHU7NCd+YdPYMAcuZa0SY3/V/lW +lNhW16jroZUxIWneX4oOKp2mqMBdKxJBqzmTJDZyj5vEkEkYPj8fxDRoMU+WooNWGBMdeVxqO2z TEbIbURsAju9lwUU5N8ezJTig5ygHcOcl9ZVVIpOncjI9U/rZlSoAeJkLudauwdHFHyEPSL8qYTy HgAAAAAAAA== From owner-ietf-smime@mail.imc.org Mon May 12 09:27: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 98BF63A6804 for ; Mon, 12 May 2008 09:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[AWL=0.256, 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 9g6Rs+pWkNxN for ; Mon, 12 May 2008 09:27:54 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 7668D3A67EE for ; Mon, 12 May 2008 09:27: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 m4CGED49021559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 09:14: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 m4CGED8i021558; Mon, 12 May 2008 09:14: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 mail-02.primus.ca (mail.tor.primus.ca [216.254.136.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4CGEBCd021533; Mon, 12 May 2008 09:14:12 -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 1JvafD-0005jd-0E; Mon, 12 May 2008 12:14:11 -0400 From: "Tony Capel" To: "'Timothy J Miller'" , "'Paul Hoffman'" Cc: "'Turner, Sean P.'" , Subject: RE: S/MIME v3.2 IDs key size text (resend, no signature) Date: Mon, 12 May 2008 12:14:03 -0400 Message-ID: <004c01c8b44b$328b0e60$02b5a8c0@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: thread-index: Aci0NleKTUV18uyISbCzl6pNQOuo+QAFGQ3Q Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sean et al: How about: 0 < key size < 512 : MAY but refer to security considerations section 512 <= key size < 1024 : SHOULD- but refer to security considerations section 1024 <= key size <= 2048 : MUST 2048 < key size : MAY but refer to security considerations section For larger keys, some text for the security considerations section might be added, e.g. something like: "A denial of service opportunity may exploitable by attackers who provide an excessively large key, or a key selected to require excessive cryptographic processing. One mitigation approach would require that the corresponding public key certificate be validated to a trusted root [trust anchor] prior to use, thus ensuring that only trusted public keys are used. However, some implementations may choose to perform signature verification (or data encryption) in parallel with certificate validation, or 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." For smaller keys, this is already addressed to some extent for encryption in the security considerations section, maybe this needs updating based on our experience with smime: Current text: 40-bit encryption is considered weak by most cryptographers. Using weak cryptography in S/MIME offers little actual security over sending plaintext. However, other features of S/MIME, such as the specification of tripleDES and the ability to announce stronger cryptographic capabilities to parties with whom you communicate, allow senders to create messages that use strong encryption. Using weak cryptography is never recommended unless the only alternative is no cryptography. When feasible, sending and receiving agents SHOULD inform senders and recipients of the relative cryptographic strength of messages. Proposed Draft text: "Using weak cryptography in S/MIME offers little actual security over sending plaintext. Some cryptographers consider public keys of less than 1024* bits to be weak, along with symmetric encryption algorithms of less than 64 bits and certain older hash algorithms used for signing. In any given application, an appropriate analysis of the threats and risks SHOULD lead to the selection of appropriate algorithms and key sizes. For public keys, algorithms and key sizes are normally defined by the public key issuer in the corresponding certificate, and thus not under the control of the end user. For symmetric encryption and hash algorithms, S/MIME supports the ability of parties to communicate their capabilities to each other, allowing the use of appropriately strong measures. When feasible, sending and receiving agents SHOULD inform senders (prior to transmission) and recipients of the relative cryptographic strength of messages and SHOULD provide a warning if weak algorithms or key sizes are used. Such warnings are especially important if the symmetric encryption or hash algorithm are significantly weaker than the corresponding public key, since this will result in a message with weaker security than that implied by the public key certificate. " Tony * of course this could be a smaller value. PS: sorry about earlier e-mail with opaque signing, I did a "Reply to" which copied the security properties from Timothy's e-mail (but not cleartext option!) - defaulting to signing which I did not intend!!! | -----Original Message----- | From: owner-ietf-smime@mail.imc.org | [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Timothy J Miller | Sent: May 12, 2008 9:31 AM | To: Paul Hoffman | Cc: Turner, Sean P.; ietf-smime@imc.org | Subject: Re: S/MIME v3.2 IDs key size text | | | | On May 9, 2008, at 4:40 PM, Paul Hoffman wrote: | > | > At 12:37 PM -0400 5/6/08, Turner, Sean P. wrote: | >> | >> 0 < key size < 511 : MUST NOT | >> 512 < key size < 1023 : SHOULD- | | > Beyond what Russ just pointed out, I find the first line to be in | > bad taste. Any IETF spec that says "you must not be able to | verify a | > signature even though it is valid" is pretty offensive. | | How about adding a "MUST warn the user that key is too damn short to | be considered safe, even though the signature is valid" | clause instead? | | -- Tim | | | -----Original Message----- | From: owner-ietf-smime@mail.imc.org | [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Timothy J Miller | Sent: May 12, 2008 9:31 AM | To: Paul Hoffman | Cc: Turner, Sean P.; ietf-smime@imc.org | Subject: Re: S/MIME v3.2 IDs key size text | | | | On May 9, 2008, at 4:40 PM, Paul Hoffman wrote: | > | > At 12:37 PM -0400 5/6/08, Turner, Sean P. wrote: | >> | >> 0 < key size < 511 : MUST NOT | >> 512 < key size < 1023 : SHOULD- | | > Beyond what Russ just pointed out, I find the first line to be in | > bad taste. Any IETF spec that says "you must not be able to | verify a | > signature even though it is valid" is pretty offensive. | | How about adding a "MUST warn the user that key is too damn short to | be considered safe, even though the signature is valid" | clause instead? | | -- Tim | | From owner-ietf-smime@mail.imc.org Mon May 12 10:08:38 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 BC1543A68DE for ; Mon, 12 May 2008 10:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 Som9eEDBwwuf for ; Mon, 12 May 2008 10:08:30 -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 9F5A73A6B7A for ; Mon, 12 May 2008 10:07: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 m4CGoPOd035204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 09:50: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 m4CGoPrQ035203; Mon, 12 May 2008 09:50:25 -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 m4CGoFGK035108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 09:50:16 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 12 May 2008 09:36:30 -0700 To: pgut001@cs.auckland.ac.nz (Peter Gutmann) From: Paul Hoffman Subject: Re: S/MIME v3.2 IDs key size text Cc: ietf-smime@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 3:32 AM +1200 5/13/08, Peter Gutmann wrote: >Paul Hoffman writes: > >>We are not the security nannies of the Internet. As long as we give a >>reasonable number of bits that all implementations should be able to sign and >>verify in order to make reasonably-strong signatures, we should step back and >>let organizations make their own rules. > >No, that's exactly what we shouldn't do, because then organisations will use >the fact that the standard doesn't set a sane limit on the key size to justify >using completely stupid key sizes (or as a generalisation completely insecure >"security" practices) [0]. You'll need to justify this one, Peter. Show me some examples where any previous version of S/MIME, none of which have "sane" lower limits, was used by any organization to justify a stupid key size. >I realise that it's not possible to explicitly >outlaw every kind of stupid behaviour that users will engage in, but since >there's a list of key sizes in the doc anyway it's a pretty trivial change to >add a sensible lower bound to it. It is a list of two elements: there is already a sensible lower bound. Please suggest specific text that would meet your criteria. From owner-ietf-smime@mail.imc.org Mon May 12 11:09:49 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 6BB5A3A6BA2 for ; Mon, 12 May 2008 11:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 qZZ782Xj6hyf for ; Mon, 12 May 2008 11:09:48 -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 356E53A6B9D for ; Mon, 12 May 2008 11:09:48 -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 m4CGoMcY035183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 09:50: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 m4CGoMPL035181; Mon, 12 May 2008 09:50: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 [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 m4CGoFGM035108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 09:50:17 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <004c01c8b44b$328b0e60$02b5a8c0@tony> References: <004c01c8b44b$328b0e60$02b5a8c0@tony> Date: Mon, 12 May 2008 09:49:00 -0700 To: "Tony Capel" From: Paul Hoffman Subject: RE: S/MIME v3.2 IDs key size text (resend, no signature) Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:14 PM -0400 5/12/08, Tony Capel wrote: >Sean et al: > >How about: > > 0 < key size < 512 : MAY but refer to security considerations >section > 512 <= key size < 1024 : SHOULD- but refer to security considerations >section >1024 <= key size <= 2048 : MUST >2048 < key size : MAY but refer to security considerations >section Could you add verbs to your table? MAY what? SHOULD- what? >"A denial of service opportunity may exploitable by attackers who provide >an excessively large key, or a key selected to require excessive >cryptographic processing. One mitigation approach would require that the >corresponding public key certificate be validated to a trusted root [trust >anchor] prior to use, thus ensuring that only trusted public keys are >used. However, some implementations may choose to perform signature >verification (or data encryption) in parallel with certificate validation, >or 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." Regardless of small key size issue, I think text like this would be a good addition to the Security Considerations section of many documents. >Proposed Draft text: > >"Using weak cryptography in S/MIME offers little actual security over >sending plaintext. >Some cryptographers consider public keys of less than 1024* bits to be >weak, along with symmetric encryption algorithms of less than 64 bits and >certain older hash algorithms used for signing. And some don't consider 1024 bits weak. For example, there are lots of 1024-bit certificates in the trust anchor pile in your browser. To date, no one is known to have compromised even one of them, even though doing so would have higher value than compromising almost any individual's signing key. Cryptographers who look at the real world of costs and benefits have noticed this. >In any given application, an appropriate analysis of the threats and risks >SHOULD lead to the selection of appropriate algorithms and key sizes. That SHOULD is misplaced. Please re-read RFC 2119. Further, we all know that this sentence is more often false than true in the real world. What is the advantage of reproducing this fairy tale in the S/MIME spec? >When feasible, sending and receiving agents SHOULD inform senders (prior >to transmission) and recipients of the relative cryptographic strength of >messages and SHOULD provide a warning if weak algorithms or key sizes are >used. I'm lost here. Using the protocol described in the document, how would I send such information? How would I send such a warning? From owner-ietf-smime@mail.imc.org Mon May 12 12:05:06 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 DEAE728C171 for ; Mon, 12 May 2008 12:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.322 X-Spam-Level: X-Spam-Status: No, score=-4.322 tagged_above=-999 required=5 tests=[AWL=2.277, 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 nkS1GHGWxxWP for ; Mon, 12 May 2008 12:05:04 -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 657F628C0EB for ; Mon, 12 May 2008 12:05:04 -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 m4CIiV9o075924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 11:44: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 m4CIiVlC075923; Mon, 12 May 2008 11:44: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 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 m4CIiTHa075879; Mon, 12 May 2008 11:44:30 -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 m4CIiR8r011806; Mon, 12 May 2008 14:44:28 -0400 Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m4CIiQc0011753; Mon, 12 May 2008 14:44:26 -0400 Received: from m5922fa48.tmodns.net ([172.31.11.160]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 May 2008 14:44:25 -0400 Cc: "Tony Capel" , Message-Id: <58461908-4572-411C-AFD5-BE8BF8A5E5FD@mitre.org> From: Timothy J Miller To: Paul Hoffman In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-16-382386151; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: S/MIME v3.2 IDs key size text (resend, no signature) Date: Mon, 12 May 2008 13:43:37 -0500 References: <004c01c8b44b$328b0e60$02b5a8c0@tony> X-Mailer: Apple Mail (2.919.2) X-OriginalArrivalTime: 12 May 2008 18:44:26.0744 (UTC) FILETIME=[344DE780:01C8B460] Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-16-382386151 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On May 12, 2008, at 11:49 AM, Paul Hoffman wrote: > >> When feasible, sending and receiving agents SHOULD inform senders >> (prior >> to transmission) and recipients of the relative cryptographic >> strength of >> messages and SHOULD provide a warning if weak algorithms or key >> sizes are >> used. > > I'm lost here. Using the protocol described in the document, how > would I send such information? How would I send such a warning? Yet similar advice exists elsewhere in the cert handling spec: """ A receiving agent SHOULD provide some explicit alternate processing of the message if this comparison fails, which may be to display a message that shows the recipient the addresses in the certificate or other certificate details. """ (ref: sec 3) Are you saying that this should come out as well, since your objection to the RFC advising implementors to warn users re: key strength clearly also applies to the RFC advising implementors re: an email mismatch? -- Tim --Apple-Mail-16-382386151 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 AUcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwNTEyMTg0MzM3 WjAjBgkqhkiG9w0BCQQxFgQU3xPlGCn4zWG6rNM43KlvJiNFnz8wcgYJKwYBBAGCNxAEMWUwYzBd MRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUG A1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIGmjB0BgsqhkiG9w0BCRACCzFl oGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowDQYJKoZIhvcNAQEB BQAEgYABTBa2ao0ryMtm/DybGB4+4jtdiKcPM7H0K03bsboq4WayEgFKQZ+z0PCCS7ExORBHKP+x HUrtbhFkN4SJVtOlR8xwNSg0VBRFFzrAeZz6rBSYznn3ohJxw3ayh22pR2YD1r6uTN2dKOBfLHm3 kWCAqeBPb/EEVcTC30rXB6/mPAAAAAAAAA== --Apple-Mail-16-382386151-- From owner-ietf-smime@mail.imc.org Mon May 12 13:29: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 0116C3A68C5 for ; Mon, 12 May 2008 13:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.357, 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 Hd7TRC+DUBQ0 for ; Mon, 12 May 2008 13:29:06 -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 B34563A67A2 for ; Mon, 12 May 2008 13:29:05 -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 m4CK8Sab007401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 13:08:28 -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 m4CK8SK6007400; Mon, 12 May 2008 13:08:28 -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 smtp109.biz.mail.re2.yahoo.com (smtp109.biz.mail.re2.yahoo.com [206.190.53.8]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m4CK8QlH007376 for ; Mon, 12 May 2008 13:08:26 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 17488 invoked from network); 12 May 2008 20:08:25 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.241.98.201 with login) by smtp109.biz.mail.re2.yahoo.com with SMTP; 12 May 2008 20:08:25 -0000 X-YMail-OSG: cBcgFMYVM1n0fcMmdKMcBD_1KDZLNKuOaICyn_nKTd3qLSN_eC.5VG0AMeOGDeDk65QvRbbmbGWpr7filzEg21oBui3etuwgTMukTjvjkeS_2Ho4VaMygjgIGsf52La8DOU- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: References: <012201c8a62a$16f76b50$0301a8c0@Wylie> from "Turner, Sean P." at Apr "24," 2008 "12:41:47" pm <200804241739.TAA28425@TR-Sys.de> Subject: RE: draft-ietf-smime-rfc3278-update-02 Date: Mon, 12 May 2008 16:08:17 -0400 Organization: IECA, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcimMjbqqRqg/Uf9Sfu6Jz1WY9sGcAOOU8IA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: <200804241739.TAA28425@TR-Sys.de> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >-----Original Message----- >From: Alfred H=CEnes [mailto:ah@tr-sys.de]=20 >Sent: Thursday, April 24, 2008 1:39 PM >To: turners@ieca.com >Cc: DBrown@certicom.com; ietf-smime@imc.org >Subject: Re: draft-ietf-smime-rfc3278-update-02 >> All, >>=20 >> Does anybody think it would be clearer to resubmit this to be a bis=20 >> draft (i.e., obsolete 3278) instead of an update draft? >> Originally, the draft just updated the ECDSA 224-512 and SHA2=20 >> algorithms, but now it updates most of the sections in RFC3278. >> I think it might be clearer to just obsolete RFC3278. >>=20 >> spt > >When it comes to security, unnecessary complexity is evil. >And complexity sometimes starts with the specification(s). > >In this case, the current draft already is an excellent=20 >example of how documents updating earlier specifications=20 >should be written to avoid any ambiguity related to what in=20 >detail is updated in which manner. > >Nevertheless, I strongly support the idea to merge the still=20 >valid parts of RFC 3278 with this draft, to obtain a single=20 >concise replacement document. There are lots of examples=20 >where RFCs have been superseded by newer ones for much less=20 >substantial updates. I haven't heard an objection to this so I'm going to submit a new -00 ID that is going to obsolete 3278 as opposed to update it. The current ID = will die on the vine. >A unified new document would also allow to update all the Refs=20 >in 3278 (including RFC-to-be 5280), split these into Normative=20 >and Informative, and adapt the boilerplate matter to the new=20 >ISOC/IETF position on IPR stuff. > >But when this step is undertaken, the next question immediately >arises: Why not also going from Informational to Standards Track? Since there's IPR with ECC all the IETF IDs/RFCs that deal with ECC are Informational. spt From owner-ietf-smime@mail.imc.org Mon May 12 13:38:24 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 E24B33A6B9C for ; Mon, 12 May 2008 13:38:23 -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 t+HWbTnkFTfk for ; Mon, 12 May 2008 13:38: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 B99123A6BAF for ; Mon, 12 May 2008 13:36:58 -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 m4CKJGmS011414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 13:19:16 -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 m4CKJGfY011412; Mon, 12 May 2008 13:19:16 -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] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4CKJEF9011388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 13:19:14 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <58461908-4572-411C-AFD5-BE8BF8A5E5FD@mitre.org> References: <004c01c8b44b$328b0e60$02b5a8c0@tony> <58461908-4572-411C-AFD5-BE8BF8A5E5FD@mitre.org> Date: Mon, 12 May 2008 13:19:10 -0700 To: Timothy J Miller From: Paul Hoffman Subject: Re: S/MIME v3.2 IDs key size text (resend, no signature) 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:43 PM -0500 5/12/08, Timothy J Miller wrote: >On May 12, 2008, at 11:49 AM, Paul Hoffman wrote: >> >>>When feasible, sending and receiving agents SHOULD inform senders (prior >>>to transmission) and recipients of the relative cryptographic strength of >>>messages and SHOULD provide a warning if weak algorithms or key sizes are >>>used. >> >>I'm lost here. Using the protocol described in the document, how >>would I send such information? How would I send such a warning? > >Yet similar advice exists elsewhere in the cert handling spec: > >""" >A receiving agent SHOULD provide some explicit alternate processing >of the message if this comparison fails, which may be to display >a message that shows the recipient the addresses in the certificate >or other certificate details. >""" (ref: sec 3) Only somewhat similar. Tony's proposed changes has a "SHOULD inform" and a "SHOULD provide a warning". The quoted test is "SHOULD provide alternate processing" which may be displaying a message. That's a big difference. >Are you saying that this should come out as well, since your >objection to the RFC advising implementors to warn users re: key >strength clearly also applies to the RFC advising implementors re: >an email mismatch? Nope. I have nothing against advising implementers. Heck, I've written a lot of the text that does that. What I object to is a SHOULD-level "inform" or "provide a warning" when we have no protocol-standard way of doing so. From owner-ietf-smime@mail.imc.org Mon May 12 14:09:59 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 18AAE3A6838 for ; Mon, 12 May 2008 14:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.461 X-Spam-Level: X-Spam-Status: No, score=-5.461 tagged_above=-999 required=5 tests=[AWL=1.138, 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 LSn5DAuo1zcB for ; Mon, 12 May 2008 14:09:58 -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 9AF803A67C0 for ; Mon, 12 May 2008 14:09: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 m4CKqEiL023301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 13:52: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 m4CKqEhl023299; Mon, 12 May 2008 13:52: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 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 m4CKqBUB023255; Mon, 12 May 2008 13:52:13 -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 m4CKqAP0002728; Mon, 12 May 2008 16:52:11 -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 m4CKqAJV002722; Mon, 12 May 2008 16:52:10 -0400 Received: from m5922fa48.tmodns.net ([172.31.11.241]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 May 2008 16:52:09 -0400 Cc: Message-Id: <93A6E28F-962E-4D08-B671-D66EB226AADC@mitre.org> From: Timothy J Miller To: Paul Hoffman In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-20-390051725; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: S/MIME v3.2 IDs key size text (resend, no signature) Date: Mon, 12 May 2008 15:51:22 -0500 References: <004c01c8b44b$328b0e60$02b5a8c0@tony> <58461908-4572-411C-AFD5-BE8BF8A5E5FD@mitre.org> X-Mailer: Apple Mail (2.919.2) X-OriginalArrivalTime: 12 May 2008 20:52:10.0369 (UTC) FILETIME=[0C2E4710:01C8B472] Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-20-390051725 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On May 12, 2008, at 3:19 PM, Paul Hoffman wrote: > Only somewhat similar. Tony's proposed changes has a "SHOULD inform" > and a "SHOULD provide a warning". The quoted test is "SHOULD provide > alternate processing" which may be displaying a message. That's a > big difference. Yet the very next paragraph says: """ A receiving agent SHOULD display a subject name or other certificate details when displaying an indication of successful or unsuccessful signature verification. """ Sounds the same to me. Here's the thing: You're advocating interpreting the spec as purely a protocol spec. If that's what you're after, then that's a bigger issue than trading barbs over key length recommendations. There are a number of clauses that require UI implementation that need to be struck out (or at least moved to the security considerations section). But here's my problem with that thinking: S/MIME isn't just a protocol, it's a ceremony. There's an fundamental UI aspect to ceremonies. This needs to be dealt with properly and *prominently* or we'll end up with implementations that don't just *allow* bad things to be done, but that *mislead users* into thinking things are true about messages that just aren't. Moving all UI-related issues or security related recommendations to a separate section lowers their visibility, and that's not a good thing IMHO. -- Tim --Apple-Mail-20-390051725 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 AUcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwNTEyMjA1MTIz WjAjBgkqhkiG9w0BCQQxFgQU5KG52Qmw3YJDsT1LUJDKcc3dPQswcgYJKwYBBAGCNxAEMWUwYzBd MRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUG A1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIGmjB0BgsqhkiG9w0BCRACCzFl oGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowDQYJKoZIhvcNAQEB BQAEgYCrSr7eoyH+LO2/OWxaAbHjRaC3E740c49RwIXTCPZzU8tE5wtL9xcw0xvdDJASQHKL0Bk/ /IRkj/u7EDSTXAUscRYO+F/TkaMZfOldCnZzMnwzUNPjy4Fv+1JCVTzAR6rnFRx312bkH1kuBj1F RPP4xRZi4bAhxzP/5nNFAVMzjAAAAAAAAA== --Apple-Mail-20-390051725-- From owner-ietf-smime@mail.imc.org Mon May 12 14:32: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 8D8C83A687E for ; Mon, 12 May 2008 14:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 CvGC5cwAQZ+9 for ; Mon, 12 May 2008 14:32:50 -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 5FC3F3A685B for ; Mon, 12 May 2008 14:32: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 m4CLF3G4032302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 14:15: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 m4CLF3XJ032300; Mon, 12 May 2008 14:15: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 [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4CLF25L032271 for ; Mon, 12 May 2008 14:15:02 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 89EA13A6BA9; Mon, 12 May 2008 14:15:03 -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-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080512211503.89EA13A6BA9@core3.amsl.com> Date: Mon, 12 May 2008 14:15:03 -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-02.txt Pages : 40 Date : 2008-5-12 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-02.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-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-5-12140710.I-D@ietf.org> --NextPart-- From owner-ietf-smime@mail.imc.org Mon May 12 14: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 E09913A687E for ; Mon, 12 May 2008 14:43:15 -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 m7W0LQBMaVl8 for ; Mon, 12 May 2008 14:43:15 -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 7FFA03A67EC for ; Mon, 12 May 2008 14:43:13 -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 m4CLQZLd036227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 14:26:35 -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 m4CLQZeI036225; Mon, 12 May 2008 14:26:35 -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] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4CLQWIj036198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 14:26:34 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <93A6E28F-962E-4D08-B671-D66EB226AADC@mitre.org> References: <004c01c8b44b$328b0e60$02b5a8c0@tony> <58461908-4572-411C-AFD5-BE8BF8A5E5FD@mitre.org> <93A6E28F-962E-4D08-B671-D66EB226AADC@mitre.org> Date: Mon, 12 May 2008 14:25:34 -0700 To: Timothy J Miller From: Paul Hoffman Subject: Re: S/MIME v3.2 IDs key size text (resend, no signature) 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 3:51 PM -0500 5/12/08, Timothy J Miller wrote: >On May 12, 2008, at 3:19 PM, Paul Hoffman wrote: > >>Only somewhat similar. Tony's proposed changes has a "SHOULD >>inform" and a "SHOULD provide a warning". The quoted test is >>"SHOULD provide alternate processing" which may be displaying a >>message. That's a big difference. > >Yet the very next paragraph says: > >""" >A receiving agent SHOULD display a subject name or other certificate >details when displaying an indication of successful or unsuccessful >signature verification. >""" > >Sounds the same to me. Reading that quoted sentence, can you see that the "SHOULD" does not apply when not "displaying an indication..."? That sentence does not mandate showing anything. If there is something in an S/MIME document that mandates "showing" or "warning", it is an error. We spent years (well, now a decade) working on this so that a conformant implementation does not need to have a UI. >Here's the thing: You're advocating interpreting the spec as purely >a protocol spec. If that's what you're after, then that's a bigger >issue than trading barbs over key length recommendations. There are >a number of clauses that require UI implementation that need to be >struck out (or at least moved to the security considerations >section). Struck out, definitely. By all means point them out. I've read this too many times to find them, I guess. >But here's my problem with that thinking: S/MIME isn't just a >protocol, it's a ceremony. There's an fundamental UI aspect to >ceremonies. I disagree strongly with the former while agreeing strongly with the latter. >This needs to be dealt with properly and *prominently* or we'll end >up with implementations that don't just *allow* bad things to be >done, but that *mislead users* into thinking things are true about >messages that just aren't. That "misleading" will happen regardless of what the spec says. It already happens now, and it happened before the IETF took over S/MIME. And it's not just S/MIME: nearly every security protocol the IETF has developed has the same problem. It's in the nature of security and users and vendors. If you want to write a BCP for implementers, that's great. This mailing list would be a great place for it to be discussed. This spec is not a BCP: it is a standard that needs to be consistent on both interoperability and security. >Moving all UI-related issues or security related recommendations to >a separate section lowers their visibility, and that's not a good >thing IMHO. It definitely lowers their visibility, and it's also the way we usually do things in the IETF. We've done it for over a decade for much higher-profile security protocols such as TLS and IPsec as well. From owner-ietf-smime@mail.imc.org Mon May 12 15:11:16 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 43F303A687E for ; Mon, 12 May 2008 15:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 6q6jKFazfsxT for ; Mon, 12 May 2008 15:11:15 -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 05EBA3A67EC for ; Mon, 12 May 2008 15:11: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 m4CLF3aI032301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 14:15: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 m4CLF36r032299; Mon, 12 May 2008 14:15: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 [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4CLF2EB032269 for ; Mon, 12 May 2008 14:15:02 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 70D133A6BA7; Mon, 12 May 2008 14:15:03 -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-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080512211503.70D133A6BA7@core3.amsl.com> Date: Mon, 12 May 2008 14:15:03 -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-02.txt Pages : 18 Date : 2008-5-12 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-02.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-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-5-12140128.I-D@ietf.org> --NextPart-- From owner-ietf-smime@mail.imc.org Mon May 12 15:16: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 3D5C73A687E for ; Mon, 12 May 2008 15:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=0.313, 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 dlYXg8X-ydXH for ; Mon, 12 May 2008 15:16:14 -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 E34E73A67B7 for ; Mon, 12 May 2008 15:16:13 -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 m4CLw7Vc048979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 14:58: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 m4CLw7c4048978; Mon, 12 May 2008 14:58: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 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 m4CLw5Ua048935 for ; Mon, 12 May 2008 14:58:06 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 18011 invoked from network); 12 May 2008 21:58:02 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.241.98.201 with login) by smtp106.biz.mail.re2.yahoo.com with SMTP; 12 May 2008 21:58:02 -0000 X-YMail-OSG: dpPPwCEVM1kxzmWd_uhpL5tPptarikE.d9AtlaWcSmY.6bDWpt62pnlyTbTYF1Bzb8fhd6rAe9o4jGAzsuvMqElsj6kA6QWTXPuHR7rkmzuQ5E.wB3BA7Eoa1JzeLQBpLDU- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "'Paul Hoffman'" , "'Tony Capel'" Cc: References: <004c01c8b44b$328b0e60$02b5a8c0@tony> Subject: RE: S/MIME v3.2 IDs key size text (resend, no signature) Date: Mon, 12 May 2008 17:57:54 -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 Thread-Index: Aci0W1KMBL1FF82SRbyczeTB2B84vQABIndg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: 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: Monday, May 12, 2008 12:49 PM >To: Tony Capel >Cc: ietf-smime@imc.org >Subject: RE: S/MIME v3.2 IDs key size text (resend, no signature) > > >At 12:14 PM -0400 5/12/08, Tony Capel wrote: >>Sean et al: >> >>How about: >> >> 0 < key size < 512 : MAY but refer to security >considerations >>section >> 512 <= key size < 1024 : SHOULD- but refer to security >considerations >>section >>1024 <= key size <= 2048 : MUST >>2048 < key size : MAY but refer to security >considerations >>section > >Could you add verbs to your table? MAY what? SHOULD- what? Not sure what Tony was thinking but I suggested that this go in 3850bis so it would have been for receiving agents. >>"A denial of service opportunity may exploitable by attackers who >>provide an excessively large key, or a key selected to require >>excessive cryptographic processing. One mitigation approach would >>require that the corresponding public key certificate be >validated to a >>trusted root [trust anchor] prior to use, thus ensuring that only >>trusted public keys are used. However, some implementations >may choose >>to perform signature verification (or data encryption) in >parallel with >>certificate validation, or 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." > >Regardless of small key size issue, I think text like this >would be a good addition to the Security Considerations >section of many documents. I had something similar in the -02 version, but I'll swap out that text for this text. spt From owner-ietf-smime@mail.imc.org Mon May 12 16:10:35 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 162063A67EC for ; Mon, 12 May 2008 16:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=-0.276, 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 7UxKmUc0lcg9 for ; Mon, 12 May 2008 16:10:34 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 11EFB3A6767 for ; Mon, 12 May 2008 16:10:34 -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 m4CMr4Y3060706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 15:53:04 -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 m4CMr48C060705; Mon, 12 May 2008 15:53:04 -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.200] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4CMr1H2060694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 15:53:02 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <004c01c8b44b$328b0e60$02b5a8c0@tony> Date: Mon, 12 May 2008 15:20:31 -0700 To: "Turner, Sean P." From: Paul Hoffman Subject: RE: S/MIME v3.2 IDs key size text (resend, no signature) 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:57 PM -0400 5/12/08, Turner, Sean P. wrote: > >-----Original Message----- >>From: owner-ietf-smime@mail.imc.org >>[mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Paul Hoffman >>Sent: Monday, May 12, 2008 12:49 PM >>To: Tony Capel >>Cc: ietf-smime@imc.org >>Subject: RE: S/MIME v3.2 IDs key size text (resend, no signature) >> >> >>At 12:14 PM -0400 5/12/08, Tony Capel wrote: >>>Sean et al: >>> >>>How about: >>> >>> 0 < key size < 512 : MAY but refer to security >>considerations >>>section >>> 512 <= key size < 1024 : SHOULD- but refer to security >>considerations >>>section >>>1024 <= key size <= 2048 : MUST >>>2048 < key size : MAY but refer to security >>considerations >>>section >> >>Could you add verbs to your table? MAY what? SHOULD- what? > >Not sure what Tony was thinking but I suggested that this go in 3850bis so >it would have been for receiving agents. In your mind, what verb goes with "SHOULD-" for a receiving agent? "SHOULD be able to verify but we won't require it in a future version"? If so, that means that we are saying "we intend to break interoperability with previous versions of this spec because of security issues". Breaking the implied stability promise we made when there is no real threat (such as people forging 768-bit signatures) seems a bit over the top. Further, such an interpretation of SHOULD- also means that we intend to deprecate 1024 bit keys in the foreseeable future even though the cryptographic security of >90% of Internet commerce is based on those keys. If the intention was to get implementers to take us seriously, saying this may not have the desired effect. From owner-ietf-smime@mail.imc.org Tue May 13 00:24: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 E9AB828C274 for ; Tue, 13 May 2008 00:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.514 X-Spam-Level: X-Spam-Status: No, score=-3.514 tagged_above=-999 required=5 tests=[AWL=-1.468, 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 vcRAO2wmcOSW for ; Tue, 13 May 2008 00:24:42 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 9611528C23D for ; Tue, 13 May 2008 00:24:41 -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 m4D6pExg081412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 23:51:20 -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 m4D6pEcm081411; Mon, 12 May 2008 23:51: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 mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4D6oCkk081275; Mon, 12 May 2008 23:50:43 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2627E48067D; Tue, 13 May 2008 18:50:10 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZdnB-R-DTxq; Tue, 13 May 2008 18:50:10 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 0C4FE48067B; Tue, 13 May 2008 18:50:09 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id B4AC419EC0BA; Tue, 13 May 2008 18:50:02 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JvoKo-0004wr-Ir; Tue, 13 May 2008 18:50:02 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, phoffman@imc.org Subject: Re: S/MIME v3.2 IDs key size text Cc: ietf-smime@imc.org In-Reply-To: Message-Id: Date: Tue, 13 May 2008 18:50:02 +1200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul Hoffman writes: >You'll need to justify this one, Peter. Show me some examples where any >previous version of S/MIME, none of which have "sane" lower limits, was used >by any organization to justify a stupid key size. How many would you like? Without naming names (if anyone really insists I could perhaps name them in private), there's an organisation using 128-bit RSA keys for access control to significant amounts of power switching gear because everyone knows that 128-bit keys are good so it should be fine for RSA. Since this is in the US I'm not that fussed about someone using it to take out their power transmission systems :-), but I think some other people might be. Uhh, Canadian health board using RSA in ECB mode to encrypt patient data, and they ended up using either 128- or 64-bit keys because otherwise things ran too slowly. Signing using 384-bit keys by a european government organisation... how many do you want, and how long have you got? I haven't got them all committed to memory so I'd have to dig back through old email and whatnot. I realise these aren't all specificially for S/MIME (the signing one was, at least for PKCS #7) but they're examples of just what people will do if the standards don't disallow it. A number of the examples came from talking to other IETF security folks so there's probably a lot more like this floating around (every time I post one of these horror-story comments I tend to get a bunch of email saying "That's nothing, you should hear this one..."). In the case of two of the three above the justification given was some variation on "if these really were no good then they'd be explicitly disallowed. Since they aren't, it's perfectly OK to do this". >Please suggest specific text that would meet your criteria. The original (proposed) MUST NOT text. There's no point in verifying a signature that you know is insecure because you know no more about the validity of the data after the verification than you did before. If the signature can't tell you anything about the validity of the data that's been signed then it should be rejected as an invalid signature because it's not serving the purpose for which it was intended. Peter. From owner-ietf-smime@mail.imc.org Tue May 13 09:40: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 06CE93A68D5 for ; Tue, 13 May 2008 09:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=-0.244, 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 XM8tbgTrAHd3 for ; Tue, 13 May 2008 09:40:35 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 15ECD3A67D4 for ; Tue, 13 May 2008 09:40: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 m4DG9oX0068327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 09:09:57 -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 m4DG9o8q068326; Tue, 13 May 2008 09:09: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 m4DG9m9O068318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 May 2008 09:09:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 13 May 2008 09:09:26 -0700 To: ietf-smime@imc.org From: Internet-Drafts@ietf.org (by way of Paul Hoffman) Subject: I-D ACTION:draft-ietf-smime-3850bis-02.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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-02.txt Pages : 18 Date : 2008-5-12 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-02.txt From owner-ietf-smime@mail.imc.org Tue May 13 10:27:24 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 2360F3A68F4 for ; Tue, 13 May 2008 10:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=-0.214, 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 EKRwz8tPzaq9 for ; Tue, 13 May 2008 10:27:23 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 1B03F3A68C8 for ; Tue, 13 May 2008 10:27:23 -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 m4DG9pTQ068334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 09:09:57 -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 m4DG9pSe068333; Tue, 13 May 2008 09:09: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 m4DG9m9Q068318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 May 2008 09:09:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 13 May 2008 09:09:46 -0700 To: ietf-smime@imc.org From: Internet-Drafts@ietf.org (by way of Paul Hoffman) Subject: I-D ACTION:draft-ietf-smime-3851bis-02.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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-02.txt Pages : 40 Date : 2008-5-12 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-02.txt From owner-ietf-smime@mail.imc.org Tue May 13 10:40: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 6379A3A68C8 for ; Tue, 13 May 2008 10:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=-0.230, 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 m2rE4Yz6qitU for ; Tue, 13 May 2008 10:40:40 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 7F4363A6805 for ; Tue, 13 May 2008 10:40: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 m4DG95FY068233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 09:09:27 -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 m4DG95Pw068232; Tue, 13 May 2008 09:09:05 -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 m4DG8jh1068155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 09:08:47 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 13 May 2008 09:08:43 -0700 To: pgut001@cs.auckland.ac.nz (Peter Gutmann) From: Paul Hoffman Subject: Re: S/MIME v3.2 IDs key size text Cc: ietf-smime@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 6:50 PM +1200 5/13/08, Peter Gutmann wrote: >Paul Hoffman writes: > >>You'll need to justify this one, Peter. Show me some examples where any >>previous version of S/MIME, none of which have "sane" lower limits, was used >>by any organization to justify a stupid key size. > >How many would you like? Only real ones that relate to this thread, thank you. >Without naming names (if anyone really insists I >could perhaps name them in private), there's an organisation using 128-bit RSA >keys for access control to significant amounts of power switching gear because >everyone knows that 128-bit keys are good so it should be fine for RSA. Since >this is in the US I'm not that fussed about someone using it to take out their >power transmission systems :-), but I think some other people might be. Uhh, >Canadian health board using RSA in ECB mode to encrypt patient data, and they >ended up using either 128- or 64-bit keys because otherwise things ran too >slowly. Signing using 384-bit keys by a european government organisation... >how many do you want, and how long have you got? I haven't got them all >committed to memory so I'd have to dig back through old email and whatnot. ...and none of these relate to the S/MIME standard, right? >I realise these aren't all specificially for S/MIME (the signing one was, at >least for PKCS #7) but they're examples of just what people will do if the >standards don't disallow it. I'll take that as a "right, they don't relate to the S/MIME standard, they're general key-size blunders". That is, the current S/MIME standard mandates being able to sign with 512-bit keys, but your examples above show that the blunderers don't do that. Please explain why you think that changing the standard will have any effect on them at all. >A number of the examples came from talking to >other IETF security folks so there's probably a lot more like this floating >around (every time I post one of these horror-story comments I tend to get a >bunch of email saying "That's nothing, you should hear this one..."). Fully agree. >In the >case of two of the three above the justification given was some variation on >"if these really were no good then they'd be explicitly disallowed. Since >they aren't, it's perfectly OK to do this". I'm skeptical, to say the least. If you have actual quotes of people saying that, fine; quoting someone third-hand through an IETF security geek is not a good way to get accurate results. > >Please suggest specific text that would meet your criteria. > >The original (proposed) MUST NOT text. There was no verb in that text. Are you supporting "MUST NOT sign with keys under 512 bits", "MUST NOT verify signatures whose keys are under 512 bits", or both? >There's no point in verifying a >signature that you know is insecure because you know no more about the >validity of the data after the verification than you did before. Fully agree. Please say why you know that every signature with keys of 511 bits is insecure, yet ones with 512 bits are secure enough. >If the >signature can't tell you anything about the validity of the data that's been >signed then it should be rejected as an invalid signature because it's not >serving the purpose for which it was intended. Fully agree. From owner-ietf-smime@mail.imc.org Tue May 13 11:18:20 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 E6CA93A67E2 for ; Tue, 13 May 2008 11:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.045 X-Spam-Level: X-Spam-Status: No, score=-4.045 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001] 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 1scLYLX-dUdR for ; Tue, 13 May 2008 11:18:20 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id E47113A67A4 for ; Tue, 13 May 2008 11:18: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 m4DHnDBm081191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 10:49:43 -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 m4DHnDn5081190; Tue, 13 May 2008 10:49: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 mail.voltage.com (mail.voltage.com [209.213.222.98]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4DHmBLc081066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 10:48:42 -0700 (MST) (envelope-from martin@voltage.com) Received: from hqmailsvr01.voltage.com (hqmailsvr01.voltage.com [172.16.0.22]) by mail.voltage.com (8.13.7/8.13.7) with ESMTP id m4DHmLOq025020 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 13 May 2008 10:48:21 -0700 Received: from hqmailsvr01.voltage.com ([172.16.0.22]) by hqmailsvr01.voltage.com ([172.16.0.22]) with mapi; Tue, 13 May 2008 10:48:00 -0700 From: Luther Martin To: "'Paul Hoffman'" , Peter Gutmann CC: "ietf-smime@imc.org" Date: Tue, 13 May 2008 10:47:59 -0700 Subject: RE: S/MIME v3.2 IDs key size text Thread-Topic: S/MIME v3.2 IDs key size text Thread-Index: Aci1Gqm7dlm/uVg0RkaxGp5uBy4bOwAAxxog Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B870629719727B4BA82A6C06A31C291203064022F4hqmailsvr01vo_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=4.65.7161:2.4.4,1.2.40,4.0.164 definitions=2008-05-13_06:2008-05-13,2008-05-13,2008-05-13 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=3.1.0-0804140000 definitions=main-0805130118 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_000_B870629719727B4BA82A6C06A31C291203064022F4hqmailsvr01vo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org= ] > On Behalf Of Paul Hoffman > >In the > >case of two of the three above the justification given was some variatio= n > on > >"if these really were no good then they'd be explicitly disallowed. > Since > >they aren't, it's perfectly OK to do this". > > I'm skeptical, to say the least. If you have actual quotes of people > saying that, fine; quoting someone third-hand through an IETF > security geek is not a good way to get accurate results. I'm with Peter on this one. I don't want to try to one-up Peter's stories (although I might be able to)= , I've also seen all sorts of blunders caused by people unfamiliar with pub= lic-key technology not understanding things that everyone on this list almo= st certainly takes for granted. I'd guess that most people who have worked = with users of public-key technology for any length of time have a similar s= et of stories. I've also seen people wanting to do make all sorts of crypto-blunders to ma= ke things easier to use, more efficient, or to comply with the letter of re= gulations instead of the spirit. So explicitly banning things that might qualify as such blunders is probabl= y a very good idea. --_000_B870629719727B4BA82A6C06A31C291203064022F4hqmailsvr01vo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> -----Original Message-----

> From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org]

> On Behalf Of Paul Hoffman

> >In the

> >case of two of the three above the justification given was some variation

> on

> >"if these really were no good then they'd be explicit= ly disallowed.

> Since

> >they aren't, it's perfectly OK to do this".

>

> I'm skeptical, to say the least. If you have actual quotes of people

> saying that, fine; quoting someone third-hand through an IETF<= o:p>

> security geek is not a good way to get accurate results.<= /o:p>

 

I'm with Peter on this one.

 

I don't want to try to one-up Peter's stories (although I might be = able to), I've also seen all sorts of blunders caused by people unfamiliar with public-key technology not understanding things that everyone on this list a= lmost certainly takes for granted. I'd guess that most people who have worked wit= h users of public-key technology for any length of time have a similar set of stories.

 

I've also seen people wanting to do make all sorts of crypto-blunde= rs to make things easier to use, more efficient, or to comply with the letter = of regulations instead of the spirit.

 

So explicitly banning things that might qualify as such blunders is probably a very good idea.

--_000_B870629719727B4BA82A6C06A31C291203064022F4hqmailsvr01vo_-- From owner-ietf-smime@mail.imc.org Tue May 13 11:33:43 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 1B3CC3A67D4 for ; Tue, 13 May 2008 11:33:43 -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 6q2WBZKVFI+v for ; Tue, 13 May 2008 11:33:42 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 4A27A3A67A4 for ; Tue, 13 May 2008 11:33:42 -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 m4DHvs5C082284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 10:57:59 -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 m4DHvsvg082283; Tue, 13 May 2008 10:57:54 -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 ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4DHvN65082230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 13 May 2008 10:57:54 -0700 (MST) (envelope-from blake@sendmail.com) Received: from spork.sendmail.com (tls.sendmail.com [209.246.26.41]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id m4DI0JDp015059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 13 May 2008 11:00:19 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1210701619; bh=FH2Y957tO6NjlIoiZae221nwDz8yazYs1V6m 4dcfdsk=; h=Received:X-DKIM:DKIM-Signature:Date:From:To:Subject: Message-ID:MIME-Version:Content-Type:Content-Disposition: User-Agent:X-MM-Ex-RefId; b=LsCO1F5MDUN5NexfozscWN2JJe14H3LeWxtZcL B8H9PvXNtbYdf2Zsfd5VWh4m8hfOnVlq1/DMnhrodC+HHnEQ3lBS+pd3FaFA1NOqaNF fgZxMfGW6DwvkVoNCzEWh6s8WbIrk9yIAZbEvR0JevKwBxx7uCLrKh/dIYzC+SdgM4= Received: from dell-desktop.example.com (c-24-17-217-200.hsd1.mn.comcast.net [24.17.217.200]) (authenticated bits=0) by spork.sendmail.com (Switch-3.3.1/Switch-3.3.2mp) with ESMTP id m4DHv6w0011254 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 13 May 2008 10:57:14 -0700 X-DKIM: Sendmail DKIM Filter v2.2.3 spork.sendmail.com m4DHv6w0011254 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=spork.dkim; t=1210701436; bh=FH2Y957tO6NjlIoiZae221nwDz8yazYs1V6m 4dcfdsk=; h=Date:From:To:Subject:Message-ID:MIME-Version: Content-Type:Content-Disposition:User-Agent:X-MM-Ex-RefId; b=f0YB6 gK7E7GvLC0mc5H0wBFsxlsSgZbOXqyPoI8vjnoJGYsjJFgY1m2hZt8tB3bN7VW5tUaF 5JNG8U7wkiYDkJ2U8MO9P0ClFB5pNFyFzGCCa5ZVKbR3tAUeQgLHJG+q/1zUcwe2dDz dPOcsKdvNwqzILI5aN2JtYWcsomemH5M= Date: Tue, 13 May 2008 10:57:06 -0700 From: Blake Ramsdell To: ietf-smime@imc.org Subject: [CAT HERDING] Key lengths for interoperability and security considerations Message-ID: <20080513175705.GA6177@dell-desktop.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-MM-Ex-RefId: 149371::080513105715-1AEDFB90-2DC85328/0-0/0-1 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: OK, so what needs to be done to come to closure on the key sizes. I think a skeleton of The Right Thing looks something like this: 1. Normative language (MUST / SHOULD with lots of plusses and minuses and atsigns) describing the minimum and maximum lengths for keys. This covers the most important area of interoperability, and needs to be very clear about signing key lengths vs. verifying key lengths vs. generating key lengths. 2. An indication by those MUST / SHOULD statements pointing to the security considerations. This is the best we can do to guide people away from using one bit keys, and steer them in the direction of strong crypto. 3. Wording in the security considerations regarding the use of overshort or overlong keys. Sean is preparing a summary of the existing discussion to address each point, and we'll see where we're at. Blake From owner-ietf-smime@mail.imc.org Tue May 13 12:48:52 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 095303A6921 for ; Tue, 13 May 2008 12:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.253 X-Spam-Level: X-Spam-Status: No, score=-3.253 tagged_above=-999 required=5 tests=[AWL=0.793, BAYES_00=-2.599, GB_I_LETTER=-2, 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 LuIgt2DETuZc for ; Tue, 13 May 2008 12:48: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 7CA883A6890 for ; Tue, 13 May 2008 12:48: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 m4DJIodR092153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 12:19:11 -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 m4DJIoZ3092152; Tue, 13 May 2008 12:18: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] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4DJIPdj092097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 12:18:25 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 13 May 2008 12:18:23 -0700 To: Luther Martin , Peter Gutmann From: Paul Hoffman Subject: RE: S/MIME v3.2 IDs key size text Cc: "ietf-smime@imc.org" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:47 AM -0700 5/13/08, Luther Martin wrote: > > -----Original Message----- > > From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] > > On Behalf Of Paul Hoffman > > >In the > > >case of two of the three above the justification given was some variation > > on > > >"if these really were no good then they'd be explicitly disallowed. > > Since > > >they aren't, it's perfectly OK to do this". > > > > I'm skeptical, to say the least. If you have actual quotes of people > > saying that, fine; quoting someone third-hand through an IETF > > security geek is not a good way to get accurate results. > >I'm with Peter on this one. > >I don't want to try to one-up Peter's stories (although I might be >able to), I've also seen all sorts of blunders caused by people >unfamiliar with public-key technology not understanding things that >everyone on this list almost certainly takes for granted. I'd guess >that most people who have worked with users of public-key technology >for any length of time have a similar set of stories. Of course this is true. What I question is Peter's assertion that putting a "don't be stupid" clause in the S/MIME RFC will cause any of them to be less stupid. In order to believe that, I want to hear someone say "I read the RFC and I still made this decision". I doubt that is true because I doubt any of these folks read the RFC. >I've also seen people wanting to do make all sorts of >crypto-blunders to make things easier to use, more efficient, or to >comply with the letter of regulations instead of the spirit. > >So explicitly banning things that might qualify as such blunders is >probably a very good idea. Maybe so, but that's not what Peter was advocating. I'm pretty sure he was supporting a statement that applications MUST NOT validate signatures that are 511 bits long while allow applications to validate signatures that are 512 bits long. From owner-ietf-smime@mail.imc.org Wed May 14 00:06: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 B069F3A685A for ; Wed, 14 May 2008 00:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.304 X-Spam-Level: X-Spam-Status: No, score=-3.304 tagged_above=-999 required=5 tests=[AWL=-1.258, 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 bi8ReSOvbb0q for ; Wed, 14 May 2008 00:06:02 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 37DD83A6830 for ; Wed, 14 May 2008 00:06:02 -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 m4E6b8lW001590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 23:37: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 m4E6b8Zw001589; Tue, 13 May 2008 23:37: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 mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4E6a6Hk001494; Tue, 13 May 2008 23:36:37 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 157FA184EC; Wed, 14 May 2008 18:36:02 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfsIQf72dlg2; Wed, 14 May 2008 18:36:01 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id EC7DA184E9; Wed, 14 May 2008 18:36:01 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id C37A819EC0BA; Wed, 14 May 2008 18:35:56 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JwAai-0007K9-L7; Wed, 14 May 2008 18:35:56 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, phoffman@imc.org Subject: Re: S/MIME v3.2 IDs key size text Cc: ietf-smime@imc.org In-Reply-To: Message-Id: Date: Wed, 14 May 2008 18:35:56 +1200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul Hoffman writes: >...and none of these relate to the S/MIME standard, right? Uhh, my posting specifically mentioned PKCS #7 signing (you actually quote the sentence right below the above comment), which the last time I checked was still S/MIME. >>How many would you like? >Only real ones that relate to this thread, thank you. Geeze, how many do you want me to dig up? The three I mentioned are ones readily to hand and ones where I knew I could mention them (in anonymised form), I'd have to ask about posting some of the others (and also spend way more time than it's worth digging through old email to locate them). In any case here's another one, from some years ago, again PKCS #7 (although PKCS #7 could probably be valid today as well, some places still don't know there's something called CMS). Anyway, some folks were using 256-bit RSA keys to send signed EDI messages around wrapped in PKCS #7 envelopes. The reason they used these was because their application, written by some contractor in Java [0], ran really slowly and their security guy [1] told them that the performance problems were because of the RSA key size being used, which was initially 1K bits (it had nothing to do with the fact that it was written in Java, it was purely the RSA key size's fault). Since they were using keys twice as large as the industry standard 128 bits and everyone knew 128 bits was totally secure, they were perfectly OK. >If you have actual quotes of people saying that, fine; quoting someone third- >hand through an IETF security geek is not a good way to get accurate results. It wasn't third-hand, it was either from me if I was involved in the work or from the person who was involved if it wasn't me [2]. In the above case (which I was directly involved with) "the standard doesn't disallow it" was the argument given for using the 256-bit keys, some mere coders tried to point out that this was wrong and the response was that there was nothing in the standard so say it was wrong and anyway the contractors had already spent X amount of time on it so unless anyone could come up with a good reason not to, it was being deployed with 256-bit RSA signatures. And so it went. Peter. [0] This was before things like Bouncy Castle were freely available and people had to build higher-level protocols from raw JCE parts with their own three hands. [1] He'd read the first two chapters of Applied Crypto. [2] Or are you saying that other members of this list, who provided some of the information, aren't reliable sources? Is there a vetting procedure they're supposed to go through first? Shall I ask for affidavits? From c0ld@c0ldvengeance.com Sun May 18 13:00: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 C39993A6DBE; Sun, 18 May 2008 13:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -65.253 X-Spam-Level: X-Spam-Status: No, score=-65.253 tagged_above=-999 required=5 tests=[FB_QUALITY_REPLICA=10.357, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=4.199, HELO_EQ_IP_ADDR=1.119, HOST_EQ_USERONOCOM=1.444, RCVD_IN_PBL=0.509, RCVD_IN_SORBS_DUL=1.615, RCVD_NUMERIC_HELO=2.599, RDNS_DYNAMIC=0.1, SARE_BAYES_5x7=0.6, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.617, 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 DVpALkWZwg3G; Sun, 18 May 2008 13:00:56 -0700 (PDT) Received: from 82.159.123.0.dyn.user.ono.com (82.159.123.0.dyn.user.ono.com [82.159.123.0]) by core3.amsl.com (Postfix) with SMTP id CBCA23A6DCF; Sun, 18 May 2008 13:00:47 -0700 (PDT) X-Originating-IP: 52.104.38.160 by smtp.82.159.123.0; Sun, 18 May 2008 16:00:46 -0500 Message-ID: From: "Andrea English" Reply-To: "Andrea English" To: sip@ietf.org Subject: Watches for him, her and you Date: Sun, 18 May 2008 16:00:46 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Prestige Replicas is a one of a kind store: the online place where you can find the highest quality replica watches at the best prices in the world! Forget about flying to China to get a mockup Cartier watch... You can now get European quality Cartier replicas at deeply discounted prices at Prestige Replicas! The best part is that our watches are so finely crafted that even the most experienced connoisseur would have a hard time telling our watches from the real deal. http://xetacafa05884.blogspot.com/ Visit Prestige Replicas today and discover a wide range of top quality Cartier replica watches offered at unbelievable prices, with a 15% discount when you buy two! http://xetacafa05884.blogspot.com/ From ca@equipaindustria.com.br Sun May 18 13:27: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 927363A6BFD; Sun, 18 May 2008 13:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -85.114 X-Spam-Level: X-Spam-Status: No, score=-85.114 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=2.188, RCVD_IN_DSBL=0.753, RCVD_IN_PBL=0.509, RCVD_IN_SORBS_DUL=1.615, RCVD_IN_XBL=2.896, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, 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 VpZkyJvOFWFg; Sun, 18 May 2008 13:27:21 -0700 (PDT) Received: from cliente-10702.iberbanda.es (unknown [82.198.105.204]) by core3.amsl.com (Postfix) with SMTP id B993A3A6800; Sun, 18 May 2008 13:27:09 -0700 (PDT) X-Originating-IP: 240.68.48.182 by smtp.82.198.105.204; Sun, 18 May 2008 16:27:10 -0500 Message-ID: From: "Terra Crum" Reply-To: "Terra Crum" To: provreg-archive@megatron.ietf.org Subject: Get 15% off these watches Date: Sun, 18 May 2008 16:27:10 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit The new Porsche Design watches originated from the novel Titanium Chronograph from the 1970's, an absolutely unique creation due to the perfection of its workmanship. Based on its design, the Porsche Design Company developed an appealing, stylish, sporty and highly accurate watch. Unfortunately, these timepieces come with a high price tag. http://rynozuhi83273.blogspot.com/ That's why a clever group of European manufacturers decided to offer the same exact functionality and style at greatly reduced prices: the Porsche Design replica watches. These replicas are so similar to the brand name pieces that it is practically impossible to tell them apart, other than by their price. They look the same, they function the same and they definitely don't have the same prices :) How would you like to browse through an amazing collection of these watches and marvel yourself with their low prices? Visit Prestige Replicas and see for yourself why sometimes replicas are so much better than the originals! http://rynozuhi83273.blogspot.com/ From c.inema@rennweg8.ch Mon May 19 04:49: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 EE6953A6B27; Mon, 19 May 2008 04:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, J_CHICKENPOX_24=0.6, 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_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_SC_SURBL=10, 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 v5UsDg-s+Z79; Mon, 19 May 2008 04:49:06 -0700 (PDT) Received: from 190-172-186-45.speedy.com.ar (unknown [190.172.186.45]) by core3.amsl.com (Postfix) with SMTP id EC39A28C5EF; Mon, 19 May 2008 04:46:59 -0700 (PDT) X-Originating-IP: 198.238.6.154 by smtp.190.172.186.45; Mon, 19 May 2008 07:46:57 -0500 Message-ID: From: "Johnny Waddell" Reply-To: "Johnny Waddell" To: sip@ietf.org Subject: Get your watch now Date: Mon, 19 May 2008 07:46:57 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Bvlgari watch is an extraordinary masterpiece that is born from the marriage of watch making and jewelry expertise. Only the most discriminating and sophisticated watch users dare put a Bv1gari on their wrists, but once the metal touches their skin, they are bound forever... How would you like to become one of the lucky few that have experienced the pleasure of sporting a Bvlgari timepiece? Now you can, and at a very reduced cost! Prestige Replicas offers a tremendous collection of Bvlgari replicas starting just a little above $200... So now there is no reason why you can't have your very own Bvlgari today! http://detylune43327.shheus.com/ From c.sohail@ndy.co.uk Mon May 19 16:54:57 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 8390F3A693F; Mon, 19 May 2008 16:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -59.627 X-Spam-Level: X-Spam-Status: No, score=-59.627 tagged_above=-999 required=5 tests=[BAYES_80=2, FB_QUALITY_REPLICA=10.357, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HELO_MISMATCH_NET=0.611, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, 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 g5hQO77dcEUc; Mon, 19 May 2008 16:54:56 -0700 (PDT) Received: from 200.79.152.27.dial.dyn.telnor.net (unknown [200.79.152.27]) by core3.amsl.com (Postfix) with SMTP id 281C23A67ED; Mon, 19 May 2008 16:54:44 -0700 (PDT) X-Originating-IP: 201.162.198.22 by smtp.200.79.152.27; Mon, 19 May 2008 19:54:42 -0500 Message-ID: From: "Charlotte Hammer" Reply-To: "Charlotte Hammer" To: sip@ietf.org Subject: One of a kind replicas Date: Mon, 19 May 2008 19:54:42 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Prestige Replicas is now bigger and better than ever before! I'm sure you're familiar with this popular replica store, so I'm glad to announce that Prestige Replicas has been completely redesigned and now offers not only the highest quality replica watches but also handbags and jewelry! In addition, they're running a 15% special these days when you buy two watches! There's never been a better time to buy a replica watch, especially a Tag Heuer! With prices as low as $200, and the store unmatched privacy assurance guarantee, I'm sure you won't want to wait to get your superior quality Tag Heuer replica! http://pawibyxagil12.blogspot.com/ From c.gebhart@wastema.de Mon May 19 17:42:39 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 DE97A3A6B51; Mon, 19 May 2008 17:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -78.772 X-Spam-Level: X-Spam-Status: No, score=-78.772 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, HELO_DYNAMIC_IPADDR2=4.395, RCVD_IN_DSBL=0.961, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, 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 9h1GUto80hqA; Mon, 19 May 2008 17:42:38 -0700 (PDT) Received: from 201-255-10-157.mrse.com.ar (unknown [201.255.10.157]) by core3.amsl.com (Postfix) with SMTP id D157F3A6B80; Mon, 19 May 2008 17:42:28 -0700 (PDT) X-Originating-IP: 122.170.12.31 by smtp.201.255.10.157; Mon, 19 May 2008 20:42:30 -0500 Message-ID: From: "Drew Lay" Reply-To: "Drew Lay" To: provreg-archive@megatron.ietf.org Subject: One of a kind replicas Date: Mon, 19 May 2008 20:42:30 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit The new Porsche Design watches originated from the novel Titanium Chronograph from the 1970's, an absolutely unique creation due to the perfection of its workmanship. Based on its design, the Porsche Design Company developed an appealing, stylish, sporty and highly accurate watch. Unfortunately, these timepieces come with a high price tag. http://myguwysecok03.blogspot.com/ That's why a clever group of European manufacturers decided to offer the same exact functionality and style at greatly reduced prices: the Porsche Design replica watches. These replicas are so similar to the brand name pieces that it is practically impossible to tell them apart, other than by their price. They look the same, they function the same and they definitely don't have the same prices :) How would you like to browse through an amazing collection of these watches and marvel yourself with their low prices? Visit Prestige Replicas and see for yourself why sometimes replicas are so much better than the originals! http://myguwysecok03.blogspot.com/ From c.vandervoort@actus.be Tue May 20 21:22: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 4D06F3A67B2; Tue, 20 May 2008 21:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.637 X-Spam-Level: X-Spam-Status: No, score=-1.637 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_QUALITY_REPLICA=10.357, FH_RELAY_NODNS=1.451, GB_ROLEX=5, HELO_EQ_MODEMCABLE=0.768, 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_XBL=3.033, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_SC_SURBL=10, 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 Fi35lxdIIBOQ; Tue, 20 May 2008 21:22:20 -0700 (PDT) Received: from Dynamic-IP-1908411957.cable.net.co (unknown [190.84.119.57]) by core3.amsl.com (Postfix) with SMTP id C898A3A67A1; Tue, 20 May 2008 21:22:15 -0700 (PDT) X-Originating-IP: 0.48.38.88 by smtp.190.84.119.57; Wed, 21 May 2008 00:22:18 -0500 Message-ID: From: "Katherine Bingham" Reply-To: "Katherine Bingham" To: provreg-archive@megatron.ietf.org Subject: You and a Rolex watch Date: Wed, 21 May 2008 00:22:18 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit X-Antivirus: avast! (VPS 080520-1, 20/05/2008), Outbound message X-Antivirus-Status: Clean Prestige Replicas is now bigger and better than ever before! I'm sure you're familiar with this popular replica store, so I'm glad to announce that Prestige Replicas has been completely redesigned and now offers not only the highest quality replica watches but also handbags and jewelry! In addition, they're running a 15% special these days when you buy two watches! There's never been a better time to buy a replica watch, especially a Tag Heuer! With prices as low as $200, and the store unmatched privacy assurance guarantee, I'm sure you won't want to wait to get your superior quality Tag Heuer replica! http://www.adieks.com/ From c.ruckendorfer@auxgazelles.at Wed May 21 09:20: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 BAD3B28C208; Wed, 21 May 2008 09:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -20.527 X-Spam-Level: X-Spam-Status: No, score=-20.527 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_DSL=1.129, 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_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_SC_SURBL=10, 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 BjV4I+J9XuHI; Wed, 21 May 2008 09:20:27 -0700 (PDT) Received: from adsl190-26162070.dyn.etb.net.co (unknown [190.26.162.70]) by core3.amsl.com (Postfix) with SMTP id D2AE928C217; Wed, 21 May 2008 09:20:13 -0700 (PDT) X-Originating-IP: 163.142.41.48 by smtp.190.26.162.70; Wed, 21 May 2008 12:20:12 -0500 Message-ID: From: "Johnny Hampton" Reply-To: "Johnny Hampton" To: sip@ietf.org Subject: Get 15% off these watches Date: Wed, 21 May 2008 12:20:12 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit An IWC watch is a uniquely handcrafted time piece that combines a classical element with a timeless elegance. Its appeal comes from their traditional beauty and their superb performance. But this sophistication has always come with a high price tag. Except of course, when you buy an IWC replica. And Prestige Replicas has dozens of IWC replica watches at prices so incredibly low that you can rest assured they won't last long! So, why not head over to Prestige Replicas right now and take a look at their IWC watches? After all, isn't it time you wore a splendid wristwatch without having to spend a fortune? http://www.adieks.com/ From owner-ietf-smime@mail.imc.org Wed May 21 10:02: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 056793A6B28 for ; Wed, 21 May 2008 10:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.064 X-Spam-Level: ** X-Spam-Status: No, score=2.064 tagged_above=-999 required=5 tests=[AWL=0.813, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 JMotYeIs5aSO for ; Wed, 21 May 2008 10:02:38 -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 DC5F328C0FE for ; Wed, 21 May 2008 10:02: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 m4LGYfeo035404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 May 2008 09:34:41 -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 m4LGYffm035402; Wed, 21 May 2008 09:34:41 -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 WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4LGYc6K035369 for ; Wed, 21 May 2008 09:34:40 -0700 (MST) (envelope-from A.Hoenes@tr-sys.de) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA269487646; Wed, 21 May 2008 18:34:06 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id SAA16803 for ietf-smime@imc.org; Wed, 21 May 2008 18:34:05 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200805211634.SAA16803@TR-Sys.de> Subject: draft-ietf-smime-3850bis-02 (fwd) To: ietf-smime@imc.org Date: Wed, 21 May 2008 18:34:04 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----- Forwarded message from Alfred HÎnes ----- From A.Hoenes@TR-Sys.de Sun May 18 16:37:14 MES 2008 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA250571434; Sun, 18 May 2008 16:37:14 +0200 Return-Path: Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id QAA11896; Sun, 18 May 2008 16:37:12 +0200 (MESZ) From: Alfred HÎnes To: blake@sendmail.com, turners@ieca.com Message-Id: <200805181437.QAA11896@TR-Sys.de> Date: Sun, 18 May 2008 16:37:12 +0200 (MESZ) Subject: draft-ietf-smime-3850bis-02 Hello, I'd like to also submit a few comments on your I-D, draft-ietf-smime-3850bis-02. (1) Conventions used ... a) I have not followed the progress of draft-hoffman-additional-key-words, but it looks like the evolution of that document might be worth being monitored or coordinated with, in order to avoid repeated re-specification of the new keywords. b) last paragraph: MUST- This term means the same as MUST. However, we expect at some point that this algorithm will no longer be a MUST in a future document. [...] I'd give preference to the word-shuffled variant: | MUST- This term means the same as MUST. However, we expect that at | some point this algorithm will no longer be a MUST in a future document. [...] (2) Section 2.2 Without explanation, the draft says: Receiving agents MUST support v1 X.509 and v3 X.509 identity certificates as profiled in [KEYM]. [...] This comes to surprise. Why are v2 certificates excluded? The deliberations in RFC 5280 seem to make v1 much less preferable. If there ideed are reasons for this particular requirement, a hint on the rationale would be useful. (3) Section 3 Below the ASN.1 fragment, please s/an upper bounds/an upper bound/ ^ (4) Section 4.3 The last paragraph says: A receiving agent MUST be capable of verifying the signatures on certificates and CRLs with key sizes from 512 bits to 2048 bits. This requirement seems to be taylored to RSA/DSA key sizes, but possibly not appropriate for the developing ECDSA context. To not inappropriately exclude shorter ECDSA key sizes and request support for unusually large ECDSA key sizes, the above statement should perhaps be restricted in scope. Matching the algorithm support requirements in the earlier parts of 4.3, but not precluding future more previce specification of ECDSA use with PKIX, CMS, and S/MIME, I propose to amend the above statement to say: vvvvvvvvvvvvv | A receiving agent MUST be capable of verifying RSA and DSA signatures on certificates and CRLs with key sizes from 512 bits to 2048 bits. (5) Sections 6 The lenghty deliberations on MD2 in this section seem to be aged, or almost historical now. Shouldn't there be some words pointing out more recent developments, in particular the perceived issues with / reduced confidence in MD5 (and perhaps also SHA-1) as well? (6) Appendix A It is very unusual to label these sections "Appendix". I suggest to renumber "Appendix A" to "Section 7". "[RFC-2822]" is the only ref. tag used incorporating an RFC number. I do not know the planned schedule, but it might happen that 2822-upd will be faster on the publication track, making a ref. update necessary. To prepare for it, and to arrive at a more homogenous ref. tag style, I suggest replacing "[RFC-2822]" by "[IMF]". For clerical completeness, I note the race condition that has occurred by nearly concurrent publication events, making the draft miss the ref. update: [KEYM] --> RFC 5280. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ ----- End of forwarded message from Alfred HÎnes ----- From owner-ietf-smime@mail.imc.org Wed May 21 10:02: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 3140F3A6A69 for ; Wed, 21 May 2008 10:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.901 X-Spam-Level: * X-Spam-Status: No, score=1.901 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 kOS5V3an+P2n for ; Wed, 21 May 2008 10:02:53 -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 B652F3A6ACB for ; Wed, 21 May 2008 10:02: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 m4LGYuFp035500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 May 2008 09:34:56 -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 m4LGYuLU035498; Wed, 21 May 2008 09:34:56 -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 WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4LGYrfM035490 for ; Wed, 21 May 2008 09:34:54 -0700 (MST) (envelope-from A.Hoenes@tr-sys.de) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA269517662; Wed, 21 May 2008 18:34:22 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id SAA16809 for ietf-smime@imc.org; Wed, 21 May 2008 18:34:21 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200805211634.SAA16809@TR-Sys.de> Subject: draft-ietf-smime-3851bis-02 (notes, part 1) (fwd) To: ietf-smime@imc.org Date: Wed, 21 May 2008 18:34:21 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----- Forwarded message from Alfred HÎnes ----- From A.Hoenes@TR-Sys.de Mon May 19 11:21:42 MES 2008 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA254648901; Mon, 19 May 2008 11:21:41 +0200 Return-Path: Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id LAA12918; Mon, 19 May 2008 11:21:38 +0200 (MESZ) From: Alfred HÎnes To: blake@sendmail.com, turners@ieca.com Cc: ietf-smime@imc.org Message-Id: <200805190921.LAA12918@TR-Sys.de> Date: Mon, 19 May 2008 11:21:38 +0200 (MESZ) Subject: draft-ietf-smime-3851bis-02 (notes, part 1) Hello, I would like to also submit a few comments on your Internet-Draft, draft-ietf-smime-3851bis-02. Due to time constraints, I have decided to split the intended comments. This is the first part addressing the initial sections of the draft, up to section 2.5.1; more will follow ASAP. (1) Conventions used ... - The RFC Editor will want to make that a proper (numbered) section. I suggest to move it to between the current sub-sections 1.1 and 1.2. - The comments I sent on the same part of draft-ietf-smime-3850bis-02 also apply. (2) Section 1 (2a) 1st paragraph For completeness (and matching of what is said in the Abtract), I suggest to add a short note on message compression to the end of the first paragraph of Section 1, for instance: As a supplementary service, S/MIME provides for message compression. (2b) 2nd paragraph Perhaps the most important usage scenario for S/MIME now is bound to SIP (using the 'sips' URIs) to protect the negotioation of multimedia session parameters (cf. RFC 3261). Therefore, I suggest to replace in the second paragraph of Section 1 the clause "such as HTTP" by "such as HTTP or SIP". (3) General -- terminology It has been generally recognized that the media type concept defined in [MIME-SPEC] has outgrown the narrow context of MIME, and RFC 4288 (BCP 13) has confirmed that the popular sluggish term "MIME Type" should not be used, in favor of the proper term "Media Type", which already had been used throughout [MIME-SPEC]. Therefore, I recommend to also change in this draft all occurrences of "MIME type" to "media type" (inclusive of the title of Section 3.4.3.1). Also, when refering to MIME header fields, their names should be quoted faithfully for clarity and precision; in particular, the hyphen should always be included after "Content", e.g., "Content type" --> "Content-type". (4) Section 1.1 (4a) 1st paragraph The draft says: This document describes a protocol for adding cryptographic signature and encryption services to MIME data. The MIME standard [MIME-SPEC] | provides a general structure for the content type of Internet | messages and allows extensions for new content type applications. There are two issues with the use of "content type": - "structure of the content type" is a slight abuse of language; "structure of content" is the proper designation. - "content type applications" seems to be vague and unclear. I suggest to use "content type specific applications" or "content type based applications" instead (4b) 2ns and 3rd paragraph Please apply (3) -- 3 occurrences. (5) Section 1.3 For clarity, please add another comma after the first instance of "inclusive", or place this word in parentheses. (6) Section 1.4 (6a) section title The legacy section title obviously is outdated, turning it ambiguous. It should better be changed: 1.4. Changes Since S/MIME v3 --- | 1.4. Changes From S/MIME v3 to S/MIME v3.1 This should properly complement the correctly entitled new section, 1.5. Changes Since S/MIME v3.1 (6b) last two paragraphs Please apply (3) -- two occurrences. (7) Section 1.5 -- typo Please replace "in parantheticals" by either "parenthetical" or "in parenthesis". (7) Section 1.5 -- typo Please replace vv v "AES-CBC" in parantheticals. by either: parenthetical "AES-CBC". or: parenthetic "AES-CBC". or: "AES-CBC" in parenthesis. (8) Section 2 -- clarification of the role of [ESS] I suggest to add a note to the text in Section 2 clarifying that RFC 2634 [ESS] is applicable for S/MIME v3.2 as well. This is intended to complement the remarks in Section 1.3 stating that RFC 2634 is part of the S/MIME v3 and S/MIME v3.1 specification. (9) Section 2.3 Please replace using rsaEncryption algorithm. by either: using the rsaEncryption algorithm. or: using rsaEncryption. (10) Section 2.4.1 The draft says: vvvvvvvvvvvv ... the MIME content MUST be stored in the SignedData encapContentInfo eContent OCTET STRING ... This is misleading; the Content-Type has to be stored there, not the "content". In line with (3) above, I suggest to use the phrase: vvvvvvvvvvv | ... the media type MUST be stored in the SignedData encapContentInfo eContent OCTET STRING ... (11) Section 2.4.4, 1st paragraph I suggest to insert the article "the" giving "reduce the message size". (12) Section 2.5 (12a) 1st paragraph The draft says, using redundant/replicated wording: vvvvvvvvvvvvv The SignerInfo type allows the inclusion of unsigned and signed attributes to be included along with a signature. ^^^^^^^^^^^^^^ I suggest to simplify the wording to: The SignerInfo type allows the inclusion of unsigned and signed | attributes along with a signature. ^ (12b) 2nd-to-last paragraph The draft says: [..]. Receiving agents SHOULD handle attributes or values that it does not recognize in a graceful manner. The wording "receiving agents ... it does not" should be improved upon. I suggest either to turn to singular: vv vv | [..]. A Receiving agent SHOULD handle attributes or values that it does not recognize in a graceful manner. or substitute "they" in the last line: [..]. Receiving agents SHOULD handle attributes or | values they do not recognize in a graceful manner. ^^^^^^^ (13) Section 2.5.1 The rules for UTCTime vs. GeneralizedTime are unfortunate for several reasons, as I have pointed out in recent comments on RFC 5280. They violate the lessons learned during Y2K that 4 decimal digits should *always* be encoded for year numbers, and they cause general non-exercising of 'MUST implement' code, generating a new security risk. I strongly recommend to, at a minimum, demote the "MUST" to encode signing-time through 2049 as UTCTime to a "MUST-", preferably "SHOULD", to promote starting general migration to GeneralizedTime. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ ----- End of forwarded message from Alfred HÎnes ----- From owner-ietf-smime@mail.imc.org Wed May 21 10:05: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 6D69628C0FE for ; Wed, 21 May 2008 10:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.093 X-Spam-Level: **** X-Spam-Status: No, score=4.093 tagged_above=-999 required=5 tests=[AWL=-1.758, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, SARE_RAND_1=2] 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 glhymms1q7cI for ; Wed, 21 May 2008 10:04:54 -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 CF7BD3A6A69 for ; Wed, 21 May 2008 10: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 m4LGZLgP035705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 May 2008 09:35:21 -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 m4LGZLkL035704; Wed, 21 May 2008 09:35:21 -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 WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4LGZHZZ035658 for ; Wed, 21 May 2008 09:35:18 -0700 (MST) (envelope-from A.Hoenes@tr-sys.de) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA269547686; Wed, 21 May 2008 18:34:46 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id SAA16815 for ietf-smime@imc.org; Wed, 21 May 2008 18:34:45 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200805211634.SAA16815@TR-Sys.de> Subject: draft-ietf-smime-3851bis-02 (notes, part 2) (fwd) To: ietf-smime@imc.org Date: Wed, 21 May 2008 18:34:44 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----- Forwarded message from Alfred HÎnes ----- From A.Hoenes@TR-Sys.de Tue May 20 16:21:51 MES 2008 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA263133310; Tue, 20 May 2008 16:21:50 +0200 Return-Path: Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id QAA14861; Tue, 20 May 2008 16:21:47 +0200 (MESZ) From: Alfred HÎnes To: blake@sendmail.com, turners@ieca.com Cc: ietf-smime@imc.org Message-Id: <200805201421.QAA14861@TR-Sys.de> Date: Tue, 20 May 2008 16:21:47 +0200 (MESZ) Subject: draft-ietf-smime-3851bis-02 (notes, part 2) Hello all, here we go with the second (and last) part of my review for draft-ietf-smime-3851bis-02 . For ease of reference, the item enumeration below extends the list from part 1 (posted yesterday). (0) Front Matter / Standards Actions The draft already indicates in its front matter: Obsoletes: 3851 During supporting investigations, it became clear that, due to specific circumstances, this will let us end up with two "valid" sets of S/MIME specifications -- those for S/MIME v3.2 and those for S/MIME v2 ! The historic reason for this scenario seems to be buried in the S/MIME v2 specifications being published as Informational RFCs and not expressly being Obsoleted by the S/MIME v3 RFCs. In Section 1.3, this draft lists RFCs 2311 through 2315 as the documents originally specifying S/MIME v2. In the RFC index, the entries for all these RFCs list INFORMATIONAL status, - RFC 2313 is tagged (Obsoleted by RFC2437), - RFC 2314 is tagged (Obsoleted by RFC2986), but - RFCs 2311, 2312, and 2315 look like being current. Arguably, it would be a matter of CMS to take action for RFC 2315, but at least RFC 2311 and RFC 2312 are clearly within scope of the S/MIME v3.2 drafts. I suggest to take the opportunity to clean up the RFC metadata and either: - also formally Obsolete the S/MIME v2 RFCs with the publication of the corresponding intended S/MIME v3.2 RFCs, (i.e. add RFC 2311 to the Obsoletes list of this draft, add RFC 2312 to the Obsoletes list of [CERT32], and defer action for RFC 2315 to CMS), or - to explicitely declare the S/MIME v2 RFCs as Historic in one place. (14) Section 2.5.3.1 The second bullet there says: - If an SMIMEEncryptionKeyPreference attribute is not found in a SignedData object received from the desired recipient, the set of X.509 certificates SHOULD be searched for a X.509 certificate | with the same subject name as the signing of a X.509 certificate ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | which can be used for key management. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I really do not understand precisely what the last two lines want to say. Please clean up and clarify. (15) Section 2.7.1.2 The visible paragraph structure there is broken; the section looks like: If the following two conditions are met: - ... - ... [[end of section]] More closely looking at the text, it turns out that fortunately the situation can be cured by inserting a paragraph break in the second bullet. For grammatical consistency, also the initial capitalization of the bullets should be changed. Thus, the section should be changed to: If the following two conditions are met: - the sending agent has no knowledge of the encryption capabilities of the recipient; and, - the sending agent has no knowledge of the version of S/MIME of the recipient, then the sending agent SHOULD use AES 128 because it is a stronger algorithm and is required by S/MIME v3.2. If the sending agent chooses not to use AES 128 in this step, it SHOULD use tripleDES. Additionally, the punctuation at the end of the first bullet now could be easily simplified: s/; and,/, and/ (16) Section 3.1 ff. -- terminological issues Being a designated Standards Track document, the draft should precisely use established IETF terminology and not occasionally fall back to common, yet sluggish (ab)use of the terms regarding the Internet message structure. Section 3.1.1 of RFC 4249 summarizes the terms established in the Internet Mail and MIME RFCs, which I will explain again in my own words: - at each conceptual protocol layer, a protocol data unit is comprised of a header and a payload (i.e., the "body" in textual protocols like email), and sometimes a trailer, as well; - the header within a protocol layer is comprised of header fields. Thus, each Internet (email) message has a single message header (Section 2.1 of I-D.2822-upd now even uses the term "message header section"). In a structured MIME message body, each nesting level has a single "MIME header", "MIME entity header", or "MIME part header" of its own (cf. RFC 2045). (We are not interested in lower level details, like MIME prologue and epilogue, etc., for the purpose of this draft.) Each message header or MIME header is comprised of header fields, with in turn consist of a field name, the colon separator, and a field value. At the MIME top level, the MIME-related header fields are integrated in the RFC[2]822 message header; they sometimes collectively are denoted as the "MIME message header". Furthermore, as explained in BCP 13, RFC 4288, the IETF should not use the popular term "MIME type", in favor of "media type". The former had not even been defined in [MIME-SPEC], and it has become even more misleading with the spread of other protocols making use of these media types. I strongly recommend to update the draft to always use this precise terminology. As a side-show, I also recommend consistently using the same spelling and capitalization for header field names -- preferably the spelling and case used in the original document defining the header field --, e.g., replace "content type" and "Content type" by "Content-Type". Because there are some subtle cases, I try to address most affected instances of these issues I found in the draft text in detail below. (17) Section 3.1 -- details (17a) 1st paragraph Applying the rationale of (16), I suggest to change (also deleting the repeated second "used" near the end of the third sentence, to streamline the language a bit): S/MIME is used to secure MIME entities. A MIME entity can be a sub- part, sub-parts of a message, or the whole message with all its sub- parts. A MIME entity that is the whole message includes only the | MIME headers and MIME body, and does not include the RFC-822 headers. ^ ^ vvvvvv ^ | Note that S/MIME can also be used to secure MIME entities used in applications other than Internet mail. If protection of the RFC-822 | headers is required, the use of the message/rfc822 MIME type is explained later in this section. --- ^^^^ S/MIME is used to secure MIME entities. A MIME entity can be a sub- part, sub-parts of a message, or the whole message with all its sub- parts. A MIME entity that is the whole message includes only the | MIME message headers and MIME body, and does not include the RFC-822 | header. Note that S/MIME can also be used to secure MIME entities in applications other than Internet mail. If protection of the RFC-822 | header is required, the use of the message/rfc822 media type is explained later in this section. (17b) 1st paragraph below 'Step 3.' Please remove the comma after "where" -- or put it in front of that "where". (17c) 2nd paragraph below 'Step 3.' Correcting a typo and applying (16), I suggest to change: | In order to protect outer, non-content related message headers (for v v ^^^^^^^ | nstance, the "Subject", "To", "From" and "CC" fields), the sending client MAY wrap a full MIME message in a message/rfc822 wrapper in | order to apply S/MIME security services to these headers. It is up ^^^^^^^ | to the receiving client to decide how to present these "inner" ^^^^^ | headers along with the unprotected "outer" headers. --- ^ ^ | In order to protect outer, non-content related message header fields | (for instance, the "Subject", "To", "From" and "Cc" fields), the sending client MAY wrap a full MIME message in a message/rfc822 | wrapper in order to apply S/MIME security services to these header | fields. It is up to the receiving client to decide how to present | this "inner" header along with the unprotected "outer" header. (18) Section 3.1.1, 2nd paragraph According to (16), please s/MIME type/media type/ (2x). (19) Section 3.1.2 According to (16): [...] If no Content-Transfer-Encoding header is present, the transfer encoding is presumed to be 7BIT. --- vvvvvv | [...] If no Content-Transfer-Encoding header field is present, the transfer encoding is presumed to be 7BIT. (20) Section 3.1.4 The legacy example of BITNET seems to be rather aged and of very low interest -- if any; cf. http://en.wikipedia.org/wiki/BITNET . I therefore suggest to simply delete " (like BITNET)" (21) Section 3.2 (21a) section title For added precision and consistency, I suggest to add "Media" in front of "Type" -- cf. 3.4.3.1, discussed in (2x) below: 3.2. The application/pkcs7-mime Type --- 3.2. The application/pkcs7-mime Media Type (21b) 3rd paragraph According to (16), please s/MIME type/media type/ (1x). (21c) last paragraph For added precision, and with respect to (16), the last sentence should be amended: | [...]. The MIME headers of all application/pkcs7-mime objects SHOULD include the optional "smime- type" parameter, as described in the following sections. --- | [...]. The Content-Type header | field of all application/pkcs7-mime objects SHOULD include the optional "smime-type" parameter, as described in the following sections. (22) Section 3.2.1, last paragraph According to (16), please s/MIME type/media type/ (1x), and s/MIME types/media types/ (1x). (23) Section 3.2.2, last numbered bullet Please correct punctuation and case: vvvv | 3. If no common string is assigned. Then the common string of "OID." is recommended (for example, "OID.1.3.6.1.5.5.7.6.1" would be DES40). --- vvv | 3. If no common string is assigned, then the common string of "OID." is recommended (for example, "OID.1.3.6.1.5.5.7.6.1" would be DES40). (24) Section 3.4.3 According to (16), please s/MIME type/media type/ (2x). (25) Section 3.4.3.1 (25a) section title With respect to (16) please change: 3.4.3.1. The application/pkcs7-signature MIME Type --- 3.4.3.1. The application/pkcs7-signature Media Type ^^^^^ (25b) 1st paragraph According to (16), please s/MIME type/media type/ (1x). (26) Section 3.4.3.2 (26a) 1st paragraph below 'Step 5' Please adjust: vv | The multipart/signed Content type has two required parameters: the protocol parameter and the micalg parameter. --- vv | The multipart/signed Content-Type has two required parameters: the protocol parameter and the micalg parameter. (26b) last paragraph: The draft says: | The SHA-224 algorithm [SHA224] and SHA-384 and SHA-512 algorithms [FIPS180-3] are not currently recommended in S/MIME, and are included here for completeness. There's an apparent disparity. SHA-224 is also covered by FIPS 180-3, and SHA-384 as well as SHA-512 are also covered by RFC 4634 not even listed as a Reference. Perhaps this has historical reasonse related to the delayed introduction of SHA-224 via a Change Notice to FIPS 180-2. Since the requirements statement is "not recommended", adding a bulk of references might be overkill; the basic Ref. should suffice. Thus, I suggest to drop [SHA224] and simplify the language: | The SHA-224, SHA-384, and SHA-512 algorithms [FIPS180-3] are not currently recommended in S/MIME, and are included here for completeness. (27) Setcion 3.9 (27a) 2nd paragraph According to (16), please change: The file suffix in the table below comes from the "name" parameter in | the content-type header, or the "filename" parameter on the content- v ^ ^ vv ^^ ^ | disposition header. These parameters that give the file suffix are not listed below as part of the parameter section. --- The file suffix in the table below comes from the "name" parameter in | the Content-Type header field, or the "filename" parameter on the | Content-Disposition header field. These parameters that give the file suffix are not listed below as part of the parameter section. (27b) table According to (16), please s/MIME type/media type/ (3x). (28) Section 4.1 The draft says: All generated key pairs MUST be generated from a good source of non- deterministic random input [RANDOM] and the private key MUST be protected in a secure fashion. IMO, this 'MUST' requirement constitutes a *Normative* Reference; so please promote '[RANDOM]' to Normative, moving the entry from B.2 to B.1. (29) Section 5 Independent on the decision to be made regarding (0) above, this section needs to be amended. (29a) Scenario 1: RFC 2311 *not* Obsoleted / made HISTORIC In this case, IANA should at least be directed to update the media type registrations for "application/pkcs7-mime" and "application/pkcs7-signature" by adding an additional reference to [RFCTHIS], in order to point the reader to the most current update of the media type information. On the other hand, updating an old media type's information arguably could require updating the registration entirely, using the new registration template from BCP 13, RFC 4288. I leave it to the high priests of exegesis (or lawyers) to figure out whether RFC 4288 in fact even normatively requests to do so. (29b) Scenario 2: RFC 2311 beinf Obsoleted or made HISTORIC In this case, the draft should substantially be amended with the two new media type registration templates, filled for both media types, "application/pkcs7-mime" and "application/pkcs7-signature", and IANA should be directed to update the registrations to incorporate this new information. (30) Section 6, 7th paragraph I suggest to make the statement on key size more specific (again, to not interfere with the future addition of other signing algorithms having other key size requirements), and to correct the placement of hyphens, as follows: Some S/MIME agents created in the United States have chosen to create | 512 bit keys in order to get more advantageous export licenses. | However, 512 bit keys are considered by many to be cryptographically insecure. --- Some S/MIME agents created in the United States have chosen to create | 512-bit RSA keys in order to get more advantageous export licenses. ^ ^^^^ v vvvv | However, 512-bit RSA keys are considered by many to be cryptographically insecure. (31) Appendix A (31a) general At first glance, it comes to surprise that there's a "~~V3dot1" ASN.1 module. For clarity, I suggest adding an introductory statement indicating that this module has been taken essentially unchanged from RFC 3851 and still applies to S/MIME v3.2. (31b) ASN.1 comment below id-cap OID definition I suggest to improve the language a bit, by inserting "OID": -- The preferBinaryInside indicates an ability to receive messages -- with binary encoding inside the CMS wrapper --- vvvvv -- The preferBinaryInside OID indicates an ability to receive -- messages with binary encoding inside the CMS wrapper. (32) Appendix B [ Interestingly, the last item for v3.2 happens to be #32 :-) ] (32a) section numbering The RFC Editor prefers References as a numbered section, not as an Appendix. Therefore, I suggest to shuffle the Appendices and turn this one into Section 7. (32b) B.1, [FIPS180-3] { oooops } vvvvvvvvvvv [FIPS180-3] "Secure Hash Signature Standard (SHS)", National Institute of Standards and Technology (NIST). FIPS Publication 180-3. --- | [FIPS180-3] "Secure Hash Standard (SHS)", National Institute of Standards and Technology (NIST), FIPS Publication | 180-3, June 2007. ^^^^^^^^^^^ or better, listing the source first (as also done for ITU-T documents): | [FIPS180-3] National Institute of Standards and Technology (NIST), | "Secure Hash Standard (SHS)", FIPS Publication 180-3, | June 2007. (32c) B.2, [RANDOM] Please add "BCP 106, " in front of "RFC 4086". regarding eventual promotion to Normative, please see item (28) above. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ ----- End of forwarded message from Alfred HÎnes ----- From c76410ac@nijiyamarket.com Wed May 21 11:00:36 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 AF8A128C216; Wed, 21 May 2008 11:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.683 X-Spam-Level: **** X-Spam-Status: No, score=4.683 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, 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, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SUB_PERFECT=0.725, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_SC_SURBL=10, 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 xhHUqPL7tzfa; Wed, 21 May 2008 11:00:34 -0700 (PDT) Received: from cable201-233-159-41.epm.net.co (cable201-233-159-41.epm.net.co [201.233.159.41]) by core3.amsl.com (Postfix) with SMTP id 6983328C210; Wed, 21 May 2008 11:00:27 -0700 (PDT) X-Originating-IP: 228.84.233.85 by smtp.201.233.159.41; Wed, 21 May 2008 14:00:33 -0500 Message-ID: From: "Verna Maynard" Reply-To: "Verna Maynard" To: provreg-archive@megatron.ietf.org Subject: Take a look at the latest replica watches Date: Wed, 21 May 2008 14:00:33 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Since 1884 Bvlgari watches have drawn inspiration from the timeless beauty of Greek and Roman art. The time pieces that they produce are as much works of art, as a way to tell time, and now you can possess one of these splendid time pieces for a very affordable price, at Prestige Replicas. http://www.adieks.com/ This store has the finest collection of Bvlgari replica watches, and you will be astounded at the difference in price as well as amazed at the quality of their timepieces. Prestige Replicas works hard to make sure that your purchase is shipped as fast as your order is processed, and also that your private information is protected. And with the new redesign of the Prestige Replicas website, we are offering 15% off on your purchase of watches! http://www.adieks.com/ From c.wisse@carlas-dance-studio.nl Thu May 22 12:05: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 F38383A6BC9; Thu, 22 May 2008 12:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -72.626 X-Spam-Level: X-Spam-Status: No, score=-72.626 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, 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 S+Os9bSMhRoD; Thu, 22 May 2008 12:05:25 -0700 (PDT) Received: from 39-141-223-201.adsl.terra.cl (39-141-223-201.adsl.terra.cl [201.223.141.39]) by core3.amsl.com (Postfix) with SMTP id 4835728C1C8; Thu, 22 May 2008 12:02:46 -0700 (PDT) X-Originating-IP: 252.116.10.245 by smtp.201.223.141.39; Thu, 22 May 2008 15:02:47 -0500 Message-ID: From: "Marcella Camp" Reply-To: "Marcella Camp" To: provreg-archive@megatron.ietf.org Subject: Watches for him, her and you Date: Thu, 22 May 2008 15:02:47 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit What comes to mind when you hear the words Louis Vuitton? Of course, the classic style, the superior quality of their bags, their unique look, and their inflated price tag. But, how about being able to afford a beautiful Louis Vuitton handbag without having to dent your budget? It is now possible. Thanks to Prestige Replicas, that Louis Vuitton bag or wallet is closer to you than ever before! Come visit our new designer bag section and pick that special Louis Vuitton handbag that you've always wanted. http://gisoxugihyd16.blogspot.com/ Remember, Prestige Replicas offers award winning customer service and an absolute guarantee of its products and your privacy! http://gisoxugihyd16.blogspot.com/ From cacton@afscmecouncil92.org Fri May 23 03:24:30 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 5AF6A3A6BB0; Fri, 23 May 2008 03:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.67 X-Spam-Level: * X-Spam-Status: No, score=1.67 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_REPLICA_ROLEX=3.157, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_ROLEX=5, HELO_DYNAMIC_IPADDR=2.426, 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, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_GENREP=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, 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 WaCvqDXTq97s; Fri, 23 May 2008 03:24:24 -0700 (PDT) Received: from ppp-124-121-200-158.revip2.asianet.co.th (ppp-124-121-200-158.revip2.asianet.co.th [124.121.200.158]) by core3.amsl.com (Postfix) with SMTP id 57B7B3A6C7A; Fri, 23 May 2008 03:24:12 -0700 (PDT) X-Originating-IP: 105.184.2.74 by smtp.124.121.200.158; Fri, 23 May 2008 06:24:12 -0500 Message-ID: From: "Russel Wooten" Reply-To: "Russel Wooten" To: provreg-archive@megatron.ietf.org Subject: Watches for him, her and you Date: Fri, 23 May 2008 06:24:12 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit When it comes down to getting a replica Rolex watch, there is just one place that offers its visitors and customers the highest quality available: Prestige Replicas. This unparalleled online store specializes in top of the line replica watches with unsurpassed performance, and bearing every marking that the genuine timepieces have. Every replica watch that Prestige Replicas carries, is made of solid stainless steel and features a sapphire crystal glass. What's more, every Rolex in store displays the green Rolex sticker with model number and logo on it. Just because you're buying a replica, don't settle for a low quality product. There are only a handful of online stores that offer the highest quality Rolex replica watches and Prestige Replicas is among them, and with the lowest available prices! http://www.oidoido.com/ From c.knight@ds-redesign.co.uk Sun May 25 12:52:45 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 E79AD3A67AA; Sun, 25 May 2008 12:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.359 X-Spam-Level: X-Spam-Status: No, score=-11.359 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DIALUP=0.862, HELO_EQ_DSL=1.129, HOST_EQ_DIALUP=0.862, HTTP_ESCAPED_HOST=0.134, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 fbWzmDveIvwH; Sun, 25 May 2008 12:52:39 -0700 (PDT) Received: from r190-135-10-220.dialup.adsl.anteldata.net.uy (r190-135-10-220.dialup.adsl.anteldata.net.uy [190.135.10.220]) by core3.amsl.com (Postfix) with SMTP id AB40C3A676A; Sun, 25 May 2008 12:52:25 -0700 (PDT) X-Originating-IP: 159.116.19.234 by smtp.190.135.10.220; Sun, 25 May 2008 15:52:38 -0500 Message-ID: From: "Elisabeth Aldrich" Reply-To: "Elisabeth Aldrich" To: provreg-archive@megatron.ietf.org Subject: Get one of these awesome replicas Date: Sun, 25 May 2008 15:52:38 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Tag Heuer watch is a luxury statement on its own. Unfortunately, that luxury comes with a price... Except when you visit Prestige Replicas, the web's most comprehensive collection of brand name replica watches. In Prestige Replicas, any Tag Heuer is available for just over $200. http://www%2Esuppoenn%2Ecom/ For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Prestige Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Prestige Replicas. http://www%2Esuppoenn%2Ecom/ From c.voelker@knebb.de Sun May 25 17:01:43 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 2FAA73A67B3; Sun, 25 May 2008 17:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.669 X-Spam-Level: X-Spam-Status: No, score=-16.669 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_24=0.6, 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_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 VAsRKWz+5D2L; Sun, 25 May 2008 17:01:37 -0700 (PDT) Received: from 190-48-137-165.speedy.com.ar (unknown [190.48.137.165]) by core3.amsl.com (Postfix) with SMTP id 022FA3A6A48; Sun, 25 May 2008 17:01:22 -0700 (PDT) X-Originating-IP: 190.229.51.134 by smtp.190.48.137.165; Sun, 25 May 2008 20:01:32 -0500 Message-ID: From: "Refugio Villa" Reply-To: "Refugio Villa" To: sip@ietf.org Subject: April promo on watches Date: Sun, 25 May 2008 20:01:32 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Bvlgari watch is an extraordinary masterpiece that is born from the marriage of watch making and jewelry expertise. Only the most discriminating and sophisticated watch users dare put a Bv1gari on their wrists, but once the metal touches their skin, they are bound forever... How would you like to become one of the lucky few that have experienced the pleasure of sporting a Bvlgari timepiece? Now you can, and at a very reduced cost! Prestige Replicas offers a tremendous collection of Bvlgari replicas starting just a little above $200... So now there is no reason why you can't have your very own Bvlgari today! http://www%2Eassieyyu%2Ecom/ From c.richter@pro-dual.de Sun May 25 23:14:45 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 DBE963A694D; Sun, 25 May 2008 23:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.233 X-Spam-Level: X-Spam-Status: No, score=-10.233 tagged_above=-999 required=5 tests=[BAYES_60=1, FB_QUALITY_REPLICA=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HTTP_ESCAPED_HOST=0.134, 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, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 Na1PRBt396uC; Sun, 25 May 2008 23:14:39 -0700 (PDT) Received: from host-70-45-1-62.onelinkpr.net (host-70-45-1-62.onelinkpr.net [70.45.1.62]) by core3.amsl.com (Postfix) with SMTP id 3AC993A6859; Sun, 25 May 2008 23:14:28 -0700 (PDT) X-Originating-IP: 0.250.193.36 by smtp.70.45.1.62; Mon, 26 May 2008 02:14:35 -0500 Message-ID: From: "Phillip Oneal" Reply-To: "Phillip Oneal" To: sip-security@ietf.org Subject: Beautiful Rado watches for less Date: Mon, 26 May 2008 02:14:35 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Prestige Replicas is now bigger and better than ever before! I'm sure you're familiar with this popular replica store, so I'm glad to announce that Prestige Replicas has been completely redesigned and now offers not only the highest quality replica watches but also handbags and jewelry! In addition, they're running a 15% special these days when you buy two watches! There's never been a better time to buy a replica watch, especially a Tag Heuer! With prices as low as $200, and the store unmatched privacy assurance guarantee, I'm sure you won't want to wait to get your superior quality Tag Heuer replica! http://www%2Eijulluise%2Ecom/ From owner-ietf-smime@mail.imc.org Mon May 26 04:19:59 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 385CE3A6A48 for ; Mon, 26 May 2008 04:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001] 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 77olWwG6+sry for ; Mon, 26 May 2008 04:19:58 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id DEFD93A68C8 for ; Mon, 26 May 2008 04:19: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 m4QAlJxd004623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 May 2008 03:47:19 -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 m4QAlJCG004622; Mon, 26 May 2008 03:47:19 -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 mx4.cryptopro.ru (mx4.cryptopro.ru [89.221.56.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4QAlFfn004586 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 26 May 2008 03:47:16 -0700 (MST) (envelope-from spv@cryptopro.ru) Received: from mx4.cryptopro.ru (192.168.68.5) by jake.cp.ru (192.168.68.8) with Microsoft SMTP Server id 8.1.263.0; Mon, 26 May 2008 14:50:15 +0400 Received: from smirnovxp64 ([192.168.68.187] RDNS failed) by mx4.cryptopro.ru with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 May 2008 14:50:15 +0400 From: "Pavel V. Smirnov" To: "'Pope, Nick'" , , Subject: Extending CAdES to support usual signature upgrading to CAdES-T and further Date: Mon, 26 May 2008 14:50:13 +0400 Message-ID: <000501c8bf1e$47cf9650$d76ec2f0$@ru> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C8BF3F.CEE13650" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aci/HkZW13VzUylGRgax42Wv2U4wnA== Content-Language: ru X-OriginalArrivalTime: 26 May 2008 10:50:15.0421 (UTC) FILETIME=[47C70AD0:01C8BF1E] Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------=_NextPart_000_0006_01C8BF3F.CEE13650 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Hello all and personally Nick, In current CAdES wording a regular signature without at least one signed attribute (Signing certificate reference) cannot be added with timestamps and validation data to achieve CAdES-T or more advanced CAdES signature. This need arises, e.g., in a system with existing regular signatures. There is no chance to add the required attribute to the already computed signature, but there is a strong need to add CAdES properties to such signatures. There is rather simple approach to achieve the same properties without including signing certificate reference as a signed attribute. Let us include this reference as an extension in the CAdES-T timestamp (signature timestamp). To get such timestamp one would need to include this extension in a timestamp request and a TSA would have to shift this extension to a timestamp token. Let us define the proposed extension to a timestamp protocol and call the signature we get a valid CAdES-T signature. More advanced CAdES signature types turn out from this new CAdES-T perfectly without any modification. What do you think? Pavel Smirnov Crypto-Pro Tel./Fax: +7 495 780-4820 WWW: http://www.CryptoPro.ru e-mail: spv@CryptoPro.ru ------=_NextPart_000_0006_01C8BF3F.CEE13650 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

Hello all and personally = Nick,

 

In current CAdES wording a = regular signature without at least one signed attribute (Signing certificate = reference) cannot be added with timestamps and validation data to achieve CAdES-T = or more advanced CAdES signature. This need arises, e.g., in a system with = existing regular signatures. There is no chance to add the required attribute to = the already computed signature, but there is a strong need to add CAdES = properties to such signatures.

 

There is rather simple approach = to achieve the same properties without including signing certificate reference as a = signed attribute. Let us include this reference as an extension in the CAdES-T timestamp (signature timestamp). To get such timestamp one would need to = include this extension in a timestamp request and a TSA would have to shift this extension to a timestamp token.

 

Let us define the proposed = extension to a timestamp protocol and call the signature we get a valid CAdES-T = signature. More advanced CAdES signature types turn out from this new CAdES-T = perfectly without any modification. What do you think?

 

Pavel Smirnov

Crypto-Pro
Tel./Fax: +7 495 780-4820
WWW: http://www.CryptoPro.ru<= span lang=3DEN-US style=3D'font-size:10.0pt;color:navy'>
e-mail: spv@CryptoPro.ru

 

------=_NextPart_000_0006_01C8BF3F.CEE13650-- From owner-ietf-smime@mail.imc.org Mon May 26 05:14:47 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 3EA413A6B8A for ; Mon, 26 May 2008 05:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.838 X-Spam-Level: X-Spam-Status: No, score=-0.838 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001] 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 a+eEbPe8IFrc for ; Mon, 26 May 2008 05:14:46 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 6D9A93A6B7A for ; Mon, 26 May 2008 05:14:46 -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 m4QAlKGZ004627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 May 2008 03:47:20 -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 m4QAlK2P004625; Mon, 26 May 2008 03:47:20 -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 mx4.cryptopro.ru (mx4.cryptopro.ru [89.221.56.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4QAlB8Q004531 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 26 May 2008 03:47:13 -0700 (MST) (envelope-from spv@cryptopro.ru) Received: from mx4.cryptopro.ru (192.168.68.5) by jake.cp.ru (192.168.68.8) with Microsoft SMTP Server id 8.1.263.0; Mon, 26 May 2008 14:50:05 +0400 Received: from smirnovxp64 ([192.168.68.187] RDNS failed) by mx4.cryptopro.ru with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 May 2008 14:50:05 +0400 From: "Pavel V. Smirnov" To: "'Pope, Nick'" , , Subject: CAdES. Storing validation data. Date: Mon, 26 May 2008 14:50:03 +0400 Message-ID: <000001c8bf1e$41ea5720$c5bf0560$@ru> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C8BF3F.C8FBF720" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aci/Hj9MN8lMCJM0TyOqb22Gph/8Bg== Content-Language: ru X-OriginalArrivalTime: 26 May 2008 10:50:05.0609 (UTC) FILETIME=[41EDD990:01C8BF1E] Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------=_NextPart_000_0001_01C8BF3F.C8FBF720 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Hello all and personally Nick, I want to draw your attention to the following problem. There is only limited possible transformation between CAdES-X Type 1 signature and CAdES-X Long Type 1 signature. Notably, one must store certificate and revocation values for signature-timestamp validation in the timestamp itself, hence, after receiving CAdES-C-timestamp one cannot add or remove these values from signature-timestamp. An obvious solution is to allow to include timestamp validation data in certificate-values and revocation-values attributes of the signature itself. What do you think? Pavel Smirnov Crypto-Pro Tel./Fax: +7 495 780-4820 WWW: http://www.CryptoPro.ru e-mail: spv@CryptoPro.ru ------=_NextPart_000_0001_01C8BF3F.C8FBF720 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

Hello all and personally = Nick,

 

I want to draw your attention to = the following problem.

 

There is only limited possible transformation between CAdES-X Type 1 signature and CAdES-X Long Type 1 signature. Notably, one must store certificate and revocation values for signature-timestamp validation in the timestamp itself, hence, after = receiving CAdES-C-timestamp one cannot add or remove these values from signature-timestamp.

 

An obvious solution is to allow = to include timestamp validation data in certificate-values and revocation-values attributes of the signature itself. What do you = think?

 

Pavel Smirnov

Crypto-Pro
Tel./Fax: +7 495 780-4820
WWW: http://www.CryptoPro.ru<= span lang=3DEN-US style=3D'font-size:10.0pt;color:navy'>
e-mail: spv@CryptoPro.ru

 

------=_NextPart_000_0001_01C8BF3F.C8FBF720-- From owner-ietf-smime@mail.imc.org Mon May 26 05:24: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 74FF83A6B8A for ; Mon, 26 May 2008 05:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.895 X-Spam-Level: ** X-Spam-Status: No, score=2.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_BAD_ID=2.837] 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 qaWso7jD+0Wd for ; Mon, 26 May 2008 05:24:03 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id C6C143A6BB4 for ; Mon, 26 May 2008 05:21: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 m4QC1c3b030257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 May 2008 05:01: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 m4QC1cEq030256; Mon, 26 May 2008 05:01: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 odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4QC1a3s030244 for ; Mon, 26 May 2008 05:01:37 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA101070; Mon, 26 May 2008 14:12:08 +0200 Received: from FRMYA-SIA24 ([129.182.109.124]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008052614010003:92025 ; Mon, 26 May 2008 14:01:00 +0200 Reply-To: denis.pinkas@bull.net From: "Denis Pinkas" To: "ETSI ESI TC", "ietf-smime" CC: "Nick Pope" Subject: Re: Extending CAdES to support usual signature upgrading to CAdES-T and further Date: Mon, 26 May 2008 14:01:00 +0200 Message-Id: References: <000501c8bf1e$47cf9650$d76ec2f0$@ru> MIME-Version: 1.0 X-Priority: 3 (Normal) X-Mailer: DreamMail 4.4.1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 26/05/2008 14:01:00, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 26/05/2008 14:01:33, Serialize complete at 26/05/2008 14:01:33 Content-Type: multipart/alternative; boundary="----=_NextPart_08052614005700783103770_002" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------=_NextPart_08052614005700783103770_002 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="ISO-8859-1" Q2FkRVMgcmVxdWlyZXMgdGhlIHNpZ25pbmcgY2VydGlmaWNhdGUgcmVmZXJlbmNlLiBUaGlzIGlz IG5vdCBnb2luZyB0byBjaGFuZ2UuDQoNCllvdSB3b3VsZCBsaWtlIHRvIHRpbWUtc3RhbXAgbm9u LUNBZEVTIHNpZ25hdHVyZXMuIFlvdSBjYW4gY2VydGFpbmx5IGRvIHRoaXMsIGJ1dCBkbyBub3Qg Y2FsbCB0aGlzIENBZEVTLVQuDQpQbGFjaW5nIHRoZSByZWZlcmVuY2UgaW4gdGhlIHRpbWUtc3Rh bXAgdG9rZW4gd291bGQgbm90IHByb3ZpZGUgdGhlIHNhbWUgcHJvdGVjdGlvbi4NCg0KUmVnYXJk cywNCg0KRGVuaXMNCg0KRGVuaXMgUGlua2FzLCBkZW5pcy5waW5rYXNAYnVsbC5uZXQNCjIwMDgt MDUtMjYgDQotLS0tLSBNZXNzYWdlIHJl53UgLS0tLS0gDQpEZSA6IG93bmVyLWlldGYtc21pbWUg DQrAIDogJ1BvcGUsTmljaycsRVNJLGlldGYtc21pbWUgDQpEYXRlIDogMjAwOC0wNS0yNiwgMTI6 NTA6MTMNClN1amV0IDogRXh0ZW5kaW5nIENBZEVTIHRvIHN1cHBvcnQgdXN1YWwgc2lnbmF0dXJl IHVwZ3JhZGluZyB0byBDQWRFUy1UIGFuZCBmdXJ0aGVyDQoNCg0KSGVsbG8gYWxsIGFuZCBwZXJz b25hbGx5IE5pY2ssDQoNCkluIGN1cnJlbnQgQ0FkRVMgd29yZGluZyBhIHJlZ3VsYXIgc2lnbmF0 dXJlIHdpdGhvdXQgYXQgbGVhc3Qgb25lIHNpZ25lZCBhdHRyaWJ1dGUgKFNpZ25pbmcgY2VydGlm aWNhdGUgcmVmZXJlbmNlKSBjYW5ub3QgYmUgYWRkZWQgd2l0aCB0aW1lc3RhbXBzIGFuZCB2YWxp ZGF0aW9uIGRhdGEgdG8gYWNoaWV2ZSBDQWRFUy1UIG9yIG1vcmUgYWR2YW5jZWQgQ0FkRVMgc2ln bmF0dXJlLiBUaGlzIG5lZWQgYXJpc2VzLCBlLmcuLCBpbiBhIHN5c3RlbSB3aXRoIGV4aXN0aW5n IHJlZ3VsYXIgc2lnbmF0dXJlcy4gVGhlcmUgaXMgbm8gY2hhbmNlIHRvIGFkZCB0aGUgcmVxdWly ZWQgYXR0cmlidXRlIHRvIHRoZSBhbHJlYWR5IGNvbXB1dGVkIHNpZ25hdHVyZSwgYnV0IHRoZXJl IGlzIGEgc3Ryb25nIG5lZWQgdG8gYWRkIENBZEVTIHByb3BlcnRpZXMgdG8gc3VjaCBzaWduYXR1 cmVzLg0KDQpUaGVyZSBpcyByYXRoZXIgc2ltcGxlIGFwcHJvYWNoIHRvIGFjaGlldmUgdGhlIHNh bWUgcHJvcGVydGllcyB3aXRob3V0IGluY2x1ZGluZyBzaWduaW5nIGNlcnRpZmljYXRlIHJlZmVy ZW5jZSBhcyBhIHNpZ25lZCBhdHRyaWJ1dGUuIExldCB1cyBpbmNsdWRlIHRoaXMgcmVmZXJlbmNl IGFzIGFuIGV4dGVuc2lvbiBpbiB0aGUgQ0FkRVMtVCB0aW1lc3RhbXAgKHNpZ25hdHVyZSB0aW1l c3RhbXApLiBUbyBnZXQgc3VjaCB0aW1lc3RhbXAgb25lIHdvdWxkIG5lZWQgdG8gaW5jbHVkZSB0 aGlzIGV4dGVuc2lvbiBpbiBhIHRpbWVzdGFtcCByZXF1ZXN0IGFuZCBhIFRTQSB3b3VsZCBoYXZl IHRvIHNoaWZ0IHRoaXMgZXh0ZW5zaW9uIHRvIGEgdGltZXN0YW1wIHRva2VuLg0KDQpMZXQgdXMg ZGVmaW5lIHRoZSBwcm9wb3NlZCBleHRlbnNpb24gdG8gYSB0aW1lc3RhbXAgcHJvdG9jb2wgYW5k IGNhbGwgdGhlIHNpZ25hdHVyZSB3ZSBnZXQgYSB2YWxpZCBDQWRFUy1UIHNpZ25hdHVyZS4gTW9y ZSBhZHZhbmNlZCBDQWRFUyBzaWduYXR1cmUgdHlwZXMgdHVybiBvdXQgZnJvbSB0aGlzIG5ldyBD QWRFUy1UIHBlcmZlY3RseSB3aXRob3V0IGFueSBtb2RpZmljYXRpb24uIFdoYXQgZG8geW91IHRo aW5rPw0KDQpQYXZlbCBTbWlybm92DQpDcnlwdG8tUHJvDQpUZWwuL0ZheDogKzcgNDk1IDc4MC00 ODIwDQpXV1c6IGh0dHA6Ly93d3cuQ3J5cHRvUHJvLnJ1DQplLW1haWw6IHNwdkBDcnlwdG9Qcm8u cnUNCg== ------=_NextPart_08052614005700783103770_002 Content-Transfer-Encoding: base64 Content-Type: text/html; charset="ISO-8859-1" PEhUTUw+PEhFQUQ+PFRJVExFPjwvVElUTEU+DQo8TUVUQSBjb250ZW50PSJLc0RIVE1MRURMaWIu b2N4LCBGcmVlV2FyZSBIVE1MIEVkaXRvciAxLjE2NC4yLCCpIEt1cnQgU2VuZmVyIiANCm5hbWU9 R0VORVJBVE9SPg0KPFNUWUxFPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMg NSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9z ZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAu TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi4uTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjoyLjBjbSA0Mi41cHQgMi4wY20gMy4wY207fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6 U2VjdGlvbjE7fQ0KLS0+DQo8L1NUWUxFPg0KDQo8TUVUQSBodHRwLWVxdWl2PUNvbnRlbnQtVHlw ZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNvLTg4NTktMSI+PC9IRUFEPg0KPEJPRFkg c3R5bGU9IkZPTlQtU0laRTogOHB0OyBGT05ULUZBTUlMWTogVGFob21hIiBsZWZ0TWFyZ2luPTUg dG9wTWFyZ2luPTUgDQojZmZmZmZmPg0KPERJVj5DYWRFUyByZXF1aXJlcyB0aGUgc2lnbmluZyBj ZXJ0aWZpY2F0ZSByZWZlcmVuY2UuIFRoaXMgaXMgbm90IGdvaW5nIHRvIA0KY2hhbmdlLjwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+WW91IHdvdWxkIGxpa2UgdG8gdGltZS1zdGFtcCBu b24tQ0FkRVMgc2lnbmF0dXJlcy4gWW91IGNhbiBjZXJ0YWlubHkgZG8gDQp0aGlzLCBidXQgZG8g bm90IGNhbGwgdGhpcyBDQWRFUy1ULjwvRElWPg0KPERJVj5QbGFjaW5nIHRoZSByZWZlcmVuY2Ug aW4gdGhlIHRpbWUtc3RhbXAgdG9rZW4gd291bGQgbm90IHByb3ZpZGUgdGhlIHNhbWUgDQpwcm90 ZWN0aW9uLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+UmVnYXJkcyw8L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+DQo8RElWPkRlbmlzPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj48L0RJVj4NCjxESVY+PCEtLUFJRF9GUk9NTkFNRV9CRUdJTi0tPkRlbmlzIFBpbmthczwhLS1B SURfRlJPTU5BTUVfRU5ELS0+LCA8QSANCmhyZWY9Im1haWx0byA6PCEtLUFJRF9GUk9NQUREUkVT U19CRUdJTi0tPmRlbmlzLnBpbmthc0BidWxsLm5ldDwhLS1BSURfRlJPTUFERFJFU1NfRU5ELS0+ Ij48IS0tQUlEX0ZST01BRERSRVNTX0JFR0lOLS0+ZGVuaXMucGlua2FzQGJ1bGwubmV0PCEtLUFJ RF9GUk9NQUREUkVTU19FTkQtLT48L0E+PC9ESVY+DQo8RElWPjIwMDgtMDUtMjYgPC9ESVY+DQo8 QkxPQ0tRVU9URSANCnN0eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7IFBBRERJTkctTEVGVDogNXB4 OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IE1BUkdJ Ti1SSUdIVDogMHB4Ij4NCiAgPERJViANCiAgc3R5bGU9IkZPTlQtV0VJR0hUOiBub3JtYWw7IEZP TlQtU0laRTogOXB0OyBMSU5FLUhFSUdIVDogbm9ybWFsOyBGT05ULVNUWUxFOiBub3JtYWw7IEZP TlQtVkFSSUFOVDogbm9ybWFsIj4tLS0tLSANCiAgTWVzc2FnZSByZed1IC0tLS0tIDwvRElWPg0K ICA8RElWIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6IG5vcm1hbDsgRk9OVC1TSVpFOiA5cHQ7IEJB Q0tHUk9VTkQ6ICNlNGU0ZTQ7IExJTkUtSEVJR0hUOiBub3JtYWw7IEZPTlQtU1RZTEU6IG5vcm1h bDsgRk9OVC1WQVJJQU5UOiBub3JtYWw7IGZvbnQtY29sb3I6IGJsYWNrIj48Qj5EZSANCiAgOjwv Qj4gPEEgaHJlZj0ibWFpbHRvIDpvd25lci1pZXRmLXNtaW1lQG1haWwuaW1jLm9yZyI+b3duZXIt aWV0Zi1zbWltZTwvQT4gDQogIDwvRElWPg0KICA8RElWIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6 IG5vcm1hbDsgRk9OVC1TSVpFOiA5cHQ7IExJTkUtSEVJR0hUOiBub3JtYWw7IEZPTlQtU1RZTEU6 IG5vcm1hbDsgRk9OVC1WQVJJQU5UOiBub3JtYWwiPjxCPsAgDQogIDo8L0I+IDxBIA0KICBocmVm PSJtYWlsdG8gOk5pY2suUG9wZUB0aGFsZXMtZXNlY3VyaXR5LmNvbSxFU0lATElTVC5FVFNJLk9S RyxpZXRmLXNtaW1lQGltYy5vcmciPidQb3BlLE5pY2snLEVTSSxpZXRmLXNtaW1lPC9BPiANCiAg PC9ESVY+DQogIDxESVYgDQogIHN0eWxlPSJGT05ULVdFSUdIVDogbm9ybWFsOyBGT05ULVNJWkU6 IDlwdDsgTElORS1IRUlHSFQ6IG5vcm1hbDsgRk9OVC1TVFlMRTogbm9ybWFsOyBGT05ULVZBUklB TlQ6IG5vcm1hbCI+PEI+RGF0ZSANCiAgOjwvQj4gMjAwOC0wNS0yNiwgMTI6NTA6MTM8L0RJVj4N CiAgPERJViANCiAgc3R5bGU9IkZPTlQtV0VJR0hUOiBub3JtYWw7IEZPTlQtU0laRTogOXB0OyBM SU5FLUhFSUdIVDogbm9ybWFsOyBGT05ULVNUWUxFOiBub3JtYWw7IEZPTlQtVkFSSUFOVDogbm9y bWFsIj48Qj5TdWpldCANCiAgOjwvQj4gRXh0ZW5kaW5nIENBZEVTIHRvIHN1cHBvcnQgdXN1YWwg c2lnbmF0dXJlIHVwZ3JhZGluZyB0byBDQWRFUy1UIGFuZCANCiAgZnVydGhlcjwvRElWPg0KICA8 RElWPjxCUj48L0RJVj4NCiAgPERJVj48L0RJVj4NCiAgPERJVj48L0RJVj4NCiAgPERJVj4NCiAg PERJViBjbGFzcz1TZWN0aW9uMT4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4t VVM+SGVsbG8gYWxsIGFuZCBwZXJzb25hbGx5IA0KICBOaWNrLDxPOlA+PC9POlA+PC9TUEFOPjwv UD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVM+PE86UD48L086UD48L1NQ QU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUz5JbiBjdXJyZW50 IENBZEVTIHdvcmRpbmcgYSByZWd1bGFyIA0KICBzaWduYXR1cmUgd2l0aG91dCBhdCBsZWFzdCBv bmUgc2lnbmVkIGF0dHJpYnV0ZSAoU2lnbmluZyBjZXJ0aWZpY2F0ZSANCiAgcmVmZXJlbmNlKSBj YW5ub3QgYmUgYWRkZWQgd2l0aCB0aW1lc3RhbXBzIGFuZCB2YWxpZGF0aW9uIGRhdGEgdG8gYWNo aWV2ZSANCiAgQ0FkRVMtVCBvciBtb3JlIGFkdmFuY2VkIENBZEVTIHNpZ25hdHVyZS4gVGhpcyBu ZWVkIGFyaXNlcywgZS5nLiwgaW4gYSBzeXN0ZW0gDQogIHdpdGggZXhpc3RpbmcgcmVndWxhciBz aWduYXR1cmVzLiBUaGVyZSBpcyBubyBjaGFuY2UgdG8gYWRkIHRoZSByZXF1aXJlZCANCiAgYXR0 cmlidXRlIHRvIHRoZSBhbHJlYWR5IGNvbXB1dGVkIHNpZ25hdHVyZSwgYnV0IHRoZXJlIGlzIGEg c3Ryb25nIG5lZWQgdG8gYWRkIA0KICBDQWRFUyBwcm9wZXJ0aWVzIHRvIHN1Y2ggc2lnbmF0dXJl cy48TzpQPjwvTzpQPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5n PUVOLVVTPjxPOlA+PC9POlA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFO IGxhbmc9RU4tVVM+VGhlcmUgaXMgcmF0aGVyIHNpbXBsZSBhcHByb2FjaCB0byBhY2hpZXZlIA0K ICB0aGUgc2FtZSBwcm9wZXJ0aWVzIHdpdGhvdXQgaW5jbHVkaW5nIHNpZ25pbmcgY2VydGlmaWNh dGUgcmVmZXJlbmNlIGFzIGEgDQogIHNpZ25lZCBhdHRyaWJ1dGUuIExldCB1cyBpbmNsdWRlIHRo aXMgcmVmZXJlbmNlIGFzIGFuIGV4dGVuc2lvbiBpbiB0aGUgQ0FkRVMtVCANCiAgdGltZXN0YW1w IChzaWduYXR1cmUgdGltZXN0YW1wKS4gVG8gZ2V0IHN1Y2ggdGltZXN0YW1wIG9uZSB3b3VsZCBu ZWVkIHRvIA0KICBpbmNsdWRlIHRoaXMgZXh0ZW5zaW9uIGluIGEgdGltZXN0YW1wIHJlcXVlc3Qg YW5kIGEgVFNBIHdvdWxkIGhhdmUgdG8gc2hpZnQgDQogIHRoaXMgZXh0ZW5zaW9uIHRvIGEgdGlt ZXN0YW1wIHRva2VuLjxPOlA+PC9POlA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFs PjxTUEFOIGxhbmc9RU4tVVM+PE86UD48L086UD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29O b3JtYWw+PFNQQU4gbGFuZz1FTi1VUz5MZXQgdXMgZGVmaW5lIHRoZSBwcm9wb3NlZCBleHRlbnNp b24gdG8gYSANCiAgdGltZXN0YW1wIHByb3RvY29sIGFuZCBjYWxsIHRoZSBzaWduYXR1cmUgd2Ug Z2V0IGEgdmFsaWQgQ0FkRVMtVCBzaWduYXR1cmUuIA0KICBNb3JlIGFkdmFuY2VkIENBZEVTIHNp Z25hdHVyZSB0eXBlcyB0dXJuIG91dCBmcm9tIHRoaXMgbmV3IENBZEVTLVQgcGVyZmVjdGx5IA0K ICB3aXRob3V0IGFueSBtb2RpZmljYXRpb24uIFdoYXQgZG8geW91IHRoaW5rPzxPOlA+PC9POlA+ PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVM+PE86UD48 L086UD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUyBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eSI+UGF2ZWwgDQogIFNtaXJub3Y8TzpQ PjwvTzpQPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVT IA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eSI+Q3J5cHRvLVBybzxCUj5U ZWwuL0ZheDogKzcgNDk1IA0KICA3ODAtNDgyMDxCUj5XV1c6IDwvU1BBTj48QSB0aXRsZT1odHRw Oi8vd3d3LmNyeXB0b3Byby5ydS8gDQogIGhyZWY9Imh0dHA6Ly93d3cuY3J5cHRvcHJvLnJ1LyI+ PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWUi Pmh0dHA6Ly93d3cuQ3J5cHRvUHJvLnJ1PC9TUEFOPjwvQT48U1BBTiANCiAgbGFuZz1FTi1VUyBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eSI+PEJSPmUtbWFpbDogPC9TUEFOPjxB IA0KICB0aXRsZT1tYWlsdG86c3B2QENyeXB0b1Byby5ydSBocmVmPSJtYWlsdG86c3B2QENyeXB0 b1Byby5ydSI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09M T1I6IGJsdWUiPnNwdkBDcnlwdG9Qcm8ucnU8L1NQQU4+PC9BPjxTUEFOIA0KICBsYW5nPUVOLVVT PjxPOlA+PC9POlA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KbGFu Zz1FTi1VUz48TzpQPjwvTzpQPjwvU1BBTj48L1A+PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPjwv Qk9EWT48L0hUTUw+DQo= ------=_NextPart_08052614005700783103770_002-- From caalvarezn@ici.ulr.cl Mon May 26 08:50: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 2546B3A69FC; Mon, 26 May 2008 08:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.187 X-Spam-Level: ** X-Spam-Status: No, score=2.187 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_24=0.6, 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_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_ROLEX_NOV5F=0.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 r0AXWVNBtsg4; Mon, 26 May 2008 08:50:04 -0700 (PDT) Received: from 200-140-111-164.gnace704.dsl.brasiltelecom.net.br (200-140-111-164.gnace704.dsl.brasiltelecom.net.br [200.140.111.164]) by core3.amsl.com (Postfix) with SMTP id E16A23A695C; Mon, 26 May 2008 08:49:49 -0700 (PDT) X-Originating-IP: 82.187.204.108 by smtp.200.24.114.53; Mon, 26 May 2008 11:49:19 -0500 Message-ID: From: "Rosalind Goodrich" Reply-To: "Rosalind Goodrich" To: sip@ietf.org Subject: Affordable brand name watches Date: Mon, 26 May 2008 11:49:19 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Bvlgari watch is an extraordinary masterpiece that is born from the marriage of watch making and jewelry expertise. Only the most discriminating and sophisticated watch users dare put a Bv1gari on their wrists, but once the metal touches their skin, they are bound forever... How would you like to become one of the lucky few that have experienced the pleasure of sporting a Bvlgari timepiece? Now you can, and at a very reduced cost! Prestige Replicas offers a tremendous collection of Bvlgari replicas starting just a little above $200... So now there is no reason why you can't have your very own Bvlgari today! http://www%2Eannsidn%2Ecom/ From c21nea@mail.maine.rr.com Mon May 26 12:24: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 530B53A6BF6; Mon, 26 May 2008 12:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -25.648 X-Spam-Level: X-Spam-Status: No, score=-25.648 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTTP_ESCAPED_HOST=0.134, 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_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 FGUfcSQgaxty; Mon, 26 May 2008 12:24:20 -0700 (PDT) Received: from host51-133-dynamic.7-87-r.retail.telecomitalia.it (host51-133-dynamic.7-87-r.retail.telecomitalia.it [87.7.133.51]) by core3.amsl.com (Postfix) with SMTP id 583213A6BF1; Mon, 26 May 2008 12:24:14 -0700 (PDT) X-Originating-IP: 149.238.172.126 by smtp.87.7.133.51; Mon, 26 May 2008 15:24:29 -0500 Message-ID: From: "Allan Tackett" Reply-To: "Allan Tackett" To: provreg-archive@megatron.ietf.org Subject: 15% off on two watches Date: Mon, 26 May 2008 15:24:29 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit X-Antivirus: avast! (VPS 080526-0, 26/05/2008), Outbound message X-Antivirus-Status: Clean Everybody knows that a Cartier watch is a silent statement of wealth and luxury. But we all know as well that the price of putting one of them on your wrist is for the most unaffordable by the average Joe. That's why replica Cartier watches are becoming more and more popular by the day. They're actually the affordable solution to this dilemma. And thanks to the internet, there is now a place where the highest quality Cartier replicas are available: Prestige Replicas. So, why not take a look at the extensive inventory that this site has to offer? After all, browsing through their hundreds of Cartier watches is absolutely free, and buying the one of your dreams is simply inexpensive. http://www%2Eselissia%2Ecom/ From c.stavroff@rubinrealestate.com Mon May 26 21:52:50 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 16A3C3A6AEC; Mon, 26 May 2008 21:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.713 X-Spam-Level: X-Spam-Status: No, score=-15.713 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, HELO_DYNAMIC_IPADDR=2.426, HTTP_ESCAPED_HOST=0.134, 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_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 seZjDiypJVFy; Mon, 26 May 2008 21:52:44 -0700 (PDT) Received: from pc-195-145-47-190.cm.vtr.net (pc-195-145-47-190.cm.vtr.net [190.47.145.195]) by core3.amsl.com (Postfix) with SMTP id A63DC3A6846; Mon, 26 May 2008 21:51:54 -0700 (PDT) X-Originating-IP: 182.132.200.204 by smtp.190.47.145.195; Tue, 27 May 2008 00:52:07 -0500 Message-ID: From: "Mickey Villarreal" Reply-To: "Mickey Villarreal" To: sip@ietf.org Subject: The discreet replica store Date: Tue, 27 May 2008 00:52:07 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit An IWC watch is a uniquely handcrafted time piece that combines a classical element with a timeless elegance. Its appeal comes from their traditional beauty and their superb performance. But this sophistication has always come with a high price tag. Except of course, when you buy an IWC replica. And Prestige Replicas has dozens of IWC replica watches at prices so incredibly low that you can rest assured they won't last long! So, why not head over to Prestige Replicas right now and take a look at their IWC watches? After all, isn't it time you wore a splendid wristwatch without having to spend a fortune? http://www%2Esuppoenn%2Ecom/ From c.serriere@serriere-deco.com Tue May 27 01:47: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 095AC3A67A1; Tue, 27 May 2008 01:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.875 X-Spam-Level: *** X-Spam-Status: No, score=3.875 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_QUALITY_REPLICA=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_ROLEX=5, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_FR=0.35, HTTP_ESCAPED_HOST=0.134, 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, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 rlkojlwzyqzy; Tue, 27 May 2008 01:47:47 -0700 (PDT) Received: from LPuteaux-151-42-40-146.w193-251.abo.wanadoo.fr (LPuteaux-151-42-40-146.w193-251.abo.wanadoo.fr [193.251.191.146]) by core3.amsl.com (Postfix) with SMTP id A17DA28C236; Tue, 27 May 2008 01:47:27 -0700 (PDT) X-Originating-IP: 185.169.96.205 by smtp.193.251.191.146; Tue, 27 May 2008 04:47:42 -0500 Message-ID: From: "Jeanine Bragg" Reply-To: "Jeanine Bragg" To: provreg-archive@megatron.ietf.org Subject: Save thousands... no one will know Date: Tue, 27 May 2008 04:47:42 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Prestige Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers. http://www%2Enunubsyy%2Ecom/ Prestige Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://www%2Enunubsyy%2Ecom/ From owner-ietf-smime@mail.imc.org Tue May 27 07:10:43 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 94C403A699F for ; Tue, 27 May 2008 07:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 s+KZ2wDuz2ZF for ; Tue, 27 May 2008 07:10:19 -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 541823A69F2 for ; Tue, 27 May 2008 07:10:18 -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 m4RDiPFr044315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 May 2008 06:44: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 m4RDiPxr044314; Tue, 27 May 2008 06:44:25 -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 [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4RDiB7a044251 for ; Tue, 27 May 2008 06:44:12 -0700 (MST) (envelope-from wwwrun@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 30) id 6DA9F3A692C; Tue, 27 May 2008 06:44:05 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , smime mailing list , smime chair Subject: Protocol Action: 'Multiple Signatures in S/MIME' to Proposed Standard Message-Id: <20080527134405.6DA9F3A692C@core3.amsl.com> Date: Tue, 27 May 2008 06:44:05 -0700 (PDT) Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the following document: - 'Multiple Signatures in S/MIME ' as a Proposed Standard This document is the product of the S/MIME Mail Security Working Group. The IESG contact persons are Tim Polk and Pasi Eronen. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-multisig-05.txt Technical Summary CMS SignedData includes the SignerInfo structure to convey per-signer information. SignedData supports multiple signers and multiple signature algorithms per-signer with multiple SignerInfo structures. If a signer attaches more than one SignerInfo, there are concerns that an attacker could perform a downgrade attack by removing the SignerInfo(s) with the 'strong' algorithm(s). This document defines the multiple-signatures attribute, its generation rules, and its processing rules to allow signers to convey multiple SignerInfo while protecting against downgrade attacks. Additionally, this attribute may assist during periods of algorithm migration. Working Group Summary This ID was discussed on the smime mailing list and at several IETF meetings. Initially, there was some confusion about the problem being solved but moving the general attacks against CMS hashes text to an Appendix addressed the WG's concerns. This initial confusion has really been the only major issue. Document Quality This document is new and there are no implementations - yet. There has been interest from multiple vendors about when it will be published as an RFC. Personnel Blake Ramsdell is the document Shepherd. Tim Polk is the responsible Security Area AD. RFC Editor Note Please make the following changes: a) Please remove the "Discussion" section preceding the Table of Contents. b) Please replace all occurrences of "pkcs9(9)" with "pkcs-9(9)". c) In section 2 list item 1), please make the following substitution OLD If both SignerInfo objects are not present, the relying party can easily determine that another SignerInfo has been removed. NEW Relying parties can easily determine that a SignerInfo has been removed if another SignerInfo contains a multi-sig attribute that refers to it. d) In section 8.1, Normative References, please make the following substitution: OLD [PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. NEW [PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. From owner-ietf-smime@mail.imc.org Sat May 31 01:12:30 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 1591B3A6B00 for ; Sat, 31 May 2008 01:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.476 X-Spam-Level: X-Spam-Status: No, score=-100.476 tagged_above=-999 required=5 tests=[AWL=-2.124, 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 HbuiYE9KKubu for ; Sat, 31 May 2008 01:12:24 -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 ED0FD3A6838 for ; Sat, 31 May 2008 01:12:23 -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 m4V7ksNM083617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 May 2008 00:46:54 -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 m4V7ksSR083616; Sat, 31 May 2008 00:46:54 -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 m4V7kodu083588 for ; Sat, 31 May 2008 00:46:52 -0700 (MST) (envelope-from iesg-secretary@ietf.org) Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1448413845; Sat, 31 May 2008 16:01:26 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm6b483c2d8f; Tue, 27 May 2008 22:00:18 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Tue, 27 May 2008 22:00:16 +0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A82643A6C41; Tue, 27 May 2008 06:44:07 -0700 (PDT) X-Original-To: ietf-announce@ietf.org Delivered-To: ietf-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 6DA9F3A692C; Tue, 27 May 2008 06:44:05 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Subject: Protocol Action: 'Multiple Signatures in S/MIME' to Proposed Standard Message-Id: <20080527134405.6DA9F3A692C@core3.amsl.com> Date: Tue, 27 May 2008 06:44:05 -0700 (PDT) Cc: Internet Architecture Board , smime chair , smime mailing list , RFC Editor X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.9 List-Id: IETF Announcements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-AIMC-AUTH: (null) X-AIMC-MAILFROM: ietf-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: iesg-secretary@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: The IESG has approved the following document: - 'Multiple Signatures in S/MIME ' as a Proposed Standard This document is the product of the S/MIME Mail Security Working Group. The IESG contact persons are Tim Polk and Pasi Eronen. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-multisig-05.txt Technical Summary CMS SignedData includes the SignerInfo structure to convey per-signer information. SignedData supports multiple signers and multiple signature algorithms per-signer with multiple SignerInfo structures. If a signer attaches more than one SignerInfo, there are concerns that an attacker could perform a downgrade attack by removing the SignerInfo(s) with the 'strong' algorithm(s). This document defines the multiple-signatures attribute, its generation rules, and its processing rules to allow signers to convey multiple SignerInfo while protecting against downgrade attacks. Additionally, this attribute may assist during periods of algorithm migration. Working Group Summary This ID was discussed on the smime mailing list and at several IETF meetings. Initially, there was some confusion about the problem being solved but moving the general attacks against CMS hashes text to an Appendix addressed the WG's concerns. This initial confusion has really been the only major issue. Document Quality This document is new and there are no implementations - yet. There has been interest from multiple vendors about when it will be published as an RFC. Personnel Blake Ramsdell is the document Shepherd. Tim Polk is the responsible Security Area AD. RFC Editor Note Please make the following changes: a) Please remove the "Discussion" section preceding the Table of Contents. b) Please replace all occurrences of "pkcs9(9)" with "pkcs-9(9)". c) In section 2 list item 1), please make the following substitution OLD If both SignerInfo objects are not present, the relying party can easily determine that another SignerInfo has been removed. NEW Relying parties can easily determine that a SignerInfo has been removed if another SignerInfo contains a multi-sig attribute that refers to it. d) In section 8.1, Normative References, please make the following substitution: OLD [PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. NEW [PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce 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 m4V7ksNM083617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 May 2008 00:46:54 -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 m4V7ksSR083616; Sat, 31 May 2008 00:46:54 -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 m4V7kodu083588 for ; Sat, 31 May 2008 00:46:52 -0700 (MST) (envelope-from iesg-secretary@ietf.org) Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1448413845; Sat, 31 May 2008 16:01:26 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm6b483c2d8f; Tue, 27 May 2008 22:00:18 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Tue, 27 May 2008 22:00:16 +0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A82643A6C41; Tue, 27 May 2008 06:44:07 -0700 (PDT) X-Original-To: ietf-announce@ietf.org Delivered-To: ietf-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 6DA9F3A692C; Tue, 27 May 2008 06:44:05 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Subject: Protocol Action: 'Multiple Signatures in S/MIME' to Proposed Standard Message-Id: <20080527134405.6DA9F3A692C@core3.amsl.com> Date: Tue, 27 May 2008 06:44:05 -0700 (PDT) Cc: Internet Architecture Board , smime chair , smime mailing list , RFC Editor X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.9 List-Id: IETF Announcements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-AIMC-AUTH: (null) X-AIMC-MAILFROM: ietf-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: iesg-secretary@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: The IESG has approved the following document: - 'Multiple Signatures in S/MIME ' as a Proposed Standard This document is the product of the S/MIME Mail Security Working Group. The IESG contact persons are Tim Polk and Pasi Eronen. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-multisig-05.txt Technical Summary CMS SignedData includes the SignerInfo structure to convey per-signer information. SignedData supports multiple signers and multiple signature algorithms per-signer with multiple SignerInfo structures. If a signer attaches more than one SignerInfo, there are concerns that an attacker could perform a downgrade attack by removing the SignerInfo(s) with the 'strong' algorithm(s). This document defines the multiple-signatures attribute, its generation rules, and its processing rules to allow signers to convey multiple SignerInfo while protecting against downgrade attacks. Additionally, this attribute may assist during periods of algorithm migration. Working Group Summary This ID was discussed on the smime mailing list and at several IETF meetings. Initially, there was some confusion about the problem being solved but moving the general attacks against CMS hashes text to an Appendix addressed the WG's concerns. This initial confusion has really been the only major issue. Document Quality This document is new and there are no implementations - yet. There has been interest from multiple vendors about when it will be published as an RFC. Personnel Blake Ramsdell is the document Shepherd. Tim Polk is the responsible Security Area AD. RFC Editor Note Please make the following changes: a) Please remove the "Discussion" section preceding the Table of Contents. b) Please replace all occurrences of "pkcs9(9)" with "pkcs-9(9)". c) In section 2 list item 1), please make the following substitution OLD If both SignerInfo objects are not present, the relying party can easily determine that another SignerInfo has been removed. NEW Relying parties can easily determine that a SignerInfo has been removed if another SignerInfo contains a multi-sig attribute that refers to it. d) In section 8.1, Normative References, please make the following substitution: OLD [PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. NEW [PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce 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 m4RDiPFr044315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 May 2008 06:44: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 m4RDiPxr044314; Tue, 27 May 2008 06:44:25 -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 [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4RDiB7a044251 for ; Tue, 27 May 2008 06:44:12 -0700 (MST) (envelope-from wwwrun@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 30) id 6DA9F3A692C; Tue, 27 May 2008 06:44:05 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , smime mailing list , smime chair Subject: Protocol Action: 'Multiple Signatures in S/MIME' to Proposed Standard Message-Id: <20080527134405.6DA9F3A692C@core3.amsl.com> Date: Tue, 27 May 2008 06:44:05 -0700 (PDT) Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the following document: - 'Multiple Signatures in S/MIME ' as a Proposed Standard This document is the product of the S/MIME Mail Security Working Group. The IESG contact persons are Tim Polk and Pasi Eronen. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-multisig-05.txt Technical Summary CMS SignedData includes the SignerInfo structure to convey per-signer information. SignedData supports multiple signers and multiple signature algorithms per-signer with multiple SignerInfo structures. If a signer attaches more than one SignerInfo, there are concerns that an attacker could perform a downgrade attack by removing the SignerInfo(s) with the 'strong' algorithm(s). This document defines the multiple-signatures attribute, its generation rules, and its processing rules to allow signers to convey multiple SignerInfo while protecting against downgrade attacks. Additionally, this attribute may assist during periods of algorithm migration. Working Group Summary This ID was discussed on the smime mailing list and at several IETF meetings. Initially, there was some confusion about the problem being solved but moving the general attacks against CMS hashes text to an Appendix addressed the WG's concerns. This initial confusion has really been the only major issue. Document Quality This document is new and there are no implementations - yet. There has been interest from multiple vendors about when it will be published as an RFC. Personnel Blake Ramsdell is the document Shepherd. Tim Polk is the responsible Security Area AD. RFC Editor Note Please make the following changes: a) Please remove the "Discussion" section preceding the Table of Contents. b) Please replace all occurrences of "pkcs9(9)" with "pkcs-9(9)". c) In section 2 list item 1), please make the following substitution OLD If both SignerInfo objects are not present, the relying party can easily determine that another SignerInfo has been removed. NEW Relying parties can easily determine that a SignerInfo has been removed if another SignerInfo contains a multi-sig attribute that refers to it. d) In section 8.1, Normative References, please make the following substitution: OLD [PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. NEW [PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. 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 m4QC1c3b030257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 May 2008 05:01: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 m4QC1cEq030256; Mon, 26 May 2008 05:01: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 odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4QC1a3s030244 for ; Mon, 26 May 2008 05:01:37 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA101070; Mon, 26 May 2008 14:12:08 +0200 Received: from FRMYA-SIA24 ([129.182.109.124]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008052614010003:92025 ; Mon, 26 May 2008 14:01:00 +0200 Reply-To: denis.pinkas@bull.net From: "Denis Pinkas" To: "ETSI ESI TC", "ietf-smime" CC: "Nick Pope" Subject: Re: Extending CAdES to support usual signature upgrading to CAdES-T and further Date: Mon, 26 May 2008 14:01:00 +0200 Message-Id: References: <000501c8bf1e$47cf9650$d76ec2f0$@ru> MIME-Version: 1.0 X-Priority: 3 (Normal) X-Mailer: DreamMail 4.4.1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 26/05/2008 14:01:00, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 26/05/2008 14:01:33, Serialize complete at 26/05/2008 14:01:33 Content-Type: multipart/alternative; boundary="----=_NextPart_08052614005700783103770_002" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------=_NextPart_08052614005700783103770_002 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="ISO-8859-1" Q2FkRVMgcmVxdWlyZXMgdGhlIHNpZ25pbmcgY2VydGlmaWNhdGUgcmVmZXJlbmNlLiBUaGlzIGlz IG5vdCBnb2luZyB0byBjaGFuZ2UuDQoNCllvdSB3b3VsZCBsaWtlIHRvIHRpbWUtc3RhbXAgbm9u LUNBZEVTIHNpZ25hdHVyZXMuIFlvdSBjYW4gY2VydGFpbmx5IGRvIHRoaXMsIGJ1dCBkbyBub3Qg Y2FsbCB0aGlzIENBZEVTLVQuDQpQbGFjaW5nIHRoZSByZWZlcmVuY2UgaW4gdGhlIHRpbWUtc3Rh bXAgdG9rZW4gd291bGQgbm90IHByb3ZpZGUgdGhlIHNhbWUgcHJvdGVjdGlvbi4NCg0KUmVnYXJk cywNCg0KRGVuaXMNCg0KRGVuaXMgUGlua2FzLCBkZW5pcy5waW5rYXNAYnVsbC5uZXQNCjIwMDgt MDUtMjYgDQotLS0tLSBNZXNzYWdlIHJl53UgLS0tLS0gDQpEZSA6IG93bmVyLWlldGYtc21pbWUg DQrAIDogJ1BvcGUsTmljaycsRVNJLGlldGYtc21pbWUgDQpEYXRlIDogMjAwOC0wNS0yNiwgMTI6 NTA6MTMNClN1amV0IDogRXh0ZW5kaW5nIENBZEVTIHRvIHN1cHBvcnQgdXN1YWwgc2lnbmF0dXJl IHVwZ3JhZGluZyB0byBDQWRFUy1UIGFuZCBmdXJ0aGVyDQoNCg0KSGVsbG8gYWxsIGFuZCBwZXJz b25hbGx5IE5pY2ssDQoNCkluIGN1cnJlbnQgQ0FkRVMgd29yZGluZyBhIHJlZ3VsYXIgc2lnbmF0 dXJlIHdpdGhvdXQgYXQgbGVhc3Qgb25lIHNpZ25lZCBhdHRyaWJ1dGUgKFNpZ25pbmcgY2VydGlm aWNhdGUgcmVmZXJlbmNlKSBjYW5ub3QgYmUgYWRkZWQgd2l0aCB0aW1lc3RhbXBzIGFuZCB2YWxp ZGF0aW9uIGRhdGEgdG8gYWNoaWV2ZSBDQWRFUy1UIG9yIG1vcmUgYWR2YW5jZWQgQ0FkRVMgc2ln bmF0dXJlLiBUaGlzIG5lZWQgYXJpc2VzLCBlLmcuLCBpbiBhIHN5c3RlbSB3aXRoIGV4aXN0aW5n IHJlZ3VsYXIgc2lnbmF0dXJlcy4gVGhlcmUgaXMgbm8gY2hhbmNlIHRvIGFkZCB0aGUgcmVxdWly ZWQgYXR0cmlidXRlIHRvIHRoZSBhbHJlYWR5IGNvbXB1dGVkIHNpZ25hdHVyZSwgYnV0IHRoZXJl IGlzIGEgc3Ryb25nIG5lZWQgdG8gYWRkIENBZEVTIHByb3BlcnRpZXMgdG8gc3VjaCBzaWduYXR1 cmVzLg0KDQpUaGVyZSBpcyByYXRoZXIgc2ltcGxlIGFwcHJvYWNoIHRvIGFjaGlldmUgdGhlIHNh bWUgcHJvcGVydGllcyB3aXRob3V0IGluY2x1ZGluZyBzaWduaW5nIGNlcnRpZmljYXRlIHJlZmVy ZW5jZSBhcyBhIHNpZ25lZCBhdHRyaWJ1dGUuIExldCB1cyBpbmNsdWRlIHRoaXMgcmVmZXJlbmNl IGFzIGFuIGV4dGVuc2lvbiBpbiB0aGUgQ0FkRVMtVCB0aW1lc3RhbXAgKHNpZ25hdHVyZSB0aW1l c3RhbXApLiBUbyBnZXQgc3VjaCB0aW1lc3RhbXAgb25lIHdvdWxkIG5lZWQgdG8gaW5jbHVkZSB0 aGlzIGV4dGVuc2lvbiBpbiBhIHRpbWVzdGFtcCByZXF1ZXN0IGFuZCBhIFRTQSB3b3VsZCBoYXZl IHRvIHNoaWZ0IHRoaXMgZXh0ZW5zaW9uIHRvIGEgdGltZXN0YW1wIHRva2VuLg0KDQpMZXQgdXMg ZGVmaW5lIHRoZSBwcm9wb3NlZCBleHRlbnNpb24gdG8gYSB0aW1lc3RhbXAgcHJvdG9jb2wgYW5k IGNhbGwgdGhlIHNpZ25hdHVyZSB3ZSBnZXQgYSB2YWxpZCBDQWRFUy1UIHNpZ25hdHVyZS4gTW9y ZSBhZHZhbmNlZCBDQWRFUyBzaWduYXR1cmUgdHlwZXMgdHVybiBvdXQgZnJvbSB0aGlzIG5ldyBD QWRFUy1UIHBlcmZlY3RseSB3aXRob3V0IGFueSBtb2RpZmljYXRpb24uIFdoYXQgZG8geW91IHRo aW5rPw0KDQpQYXZlbCBTbWlybm92DQpDcnlwdG8tUHJvDQpUZWwuL0ZheDogKzcgNDk1IDc4MC00 ODIwDQpXV1c6IGh0dHA6Ly93d3cuQ3J5cHRvUHJvLnJ1DQplLW1haWw6IHNwdkBDcnlwdG9Qcm8u cnUNCg== ------=_NextPart_08052614005700783103770_002 Content-Transfer-Encoding: base64 Content-Type: text/html; charset="ISO-8859-1" PEhUTUw+PEhFQUQ+PFRJVExFPjwvVElUTEU+DQo8TUVUQSBjb250ZW50PSJLc0RIVE1MRURMaWIu b2N4LCBGcmVlV2FyZSBIVE1MIEVkaXRvciAxLjE2NC4yLCCpIEt1cnQgU2VuZmVyIiANCm5hbWU9 R0VORVJBVE9SPg0KPFNUWUxFPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMg NSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9z ZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAu TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi4uTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjoyLjBjbSA0Mi41cHQgMi4wY20gMy4wY207fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6 U2VjdGlvbjE7fQ0KLS0+DQo8L1NUWUxFPg0KDQo8TUVUQSBodHRwLWVxdWl2PUNvbnRlbnQtVHlw ZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNvLTg4NTktMSI+PC9IRUFEPg0KPEJPRFkg c3R5bGU9IkZPTlQtU0laRTogOHB0OyBGT05ULUZBTUlMWTogVGFob21hIiBsZWZ0TWFyZ2luPTUg dG9wTWFyZ2luPTUgDQojZmZmZmZmPg0KPERJVj5DYWRFUyByZXF1aXJlcyB0aGUgc2lnbmluZyBj ZXJ0aWZpY2F0ZSByZWZlcmVuY2UuIFRoaXMgaXMgbm90IGdvaW5nIHRvIA0KY2hhbmdlLjwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+WW91IHdvdWxkIGxpa2UgdG8gdGltZS1zdGFtcCBu b24tQ0FkRVMgc2lnbmF0dXJlcy4gWW91IGNhbiBjZXJ0YWlubHkgZG8gDQp0aGlzLCBidXQgZG8g bm90IGNhbGwgdGhpcyBDQWRFUy1ULjwvRElWPg0KPERJVj5QbGFjaW5nIHRoZSByZWZlcmVuY2Ug aW4gdGhlIHRpbWUtc3RhbXAgdG9rZW4gd291bGQgbm90IHByb3ZpZGUgdGhlIHNhbWUgDQpwcm90 ZWN0aW9uLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+UmVnYXJkcyw8L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+DQo8RElWPkRlbmlzPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj48L0RJVj4NCjxESVY+PCEtLUFJRF9GUk9NTkFNRV9CRUdJTi0tPkRlbmlzIFBpbmthczwhLS1B SURfRlJPTU5BTUVfRU5ELS0+LCA8QSANCmhyZWY9Im1haWx0byA6PCEtLUFJRF9GUk9NQUREUkVT U19CRUdJTi0tPmRlbmlzLnBpbmthc0BidWxsLm5ldDwhLS1BSURfRlJPTUFERFJFU1NfRU5ELS0+ Ij48IS0tQUlEX0ZST01BRERSRVNTX0JFR0lOLS0+ZGVuaXMucGlua2FzQGJ1bGwubmV0PCEtLUFJ RF9GUk9NQUREUkVTU19FTkQtLT48L0E+PC9ESVY+DQo8RElWPjIwMDgtMDUtMjYgPC9ESVY+DQo8 QkxPQ0tRVU9URSANCnN0eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7IFBBRERJTkctTEVGVDogNXB4 OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IE1BUkdJ Ti1SSUdIVDogMHB4Ij4NCiAgPERJViANCiAgc3R5bGU9IkZPTlQtV0VJR0hUOiBub3JtYWw7IEZP TlQtU0laRTogOXB0OyBMSU5FLUhFSUdIVDogbm9ybWFsOyBGT05ULVNUWUxFOiBub3JtYWw7IEZP TlQtVkFSSUFOVDogbm9ybWFsIj4tLS0tLSANCiAgTWVzc2FnZSByZed1IC0tLS0tIDwvRElWPg0K ICA8RElWIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6IG5vcm1hbDsgRk9OVC1TSVpFOiA5cHQ7IEJB Q0tHUk9VTkQ6ICNlNGU0ZTQ7IExJTkUtSEVJR0hUOiBub3JtYWw7IEZPTlQtU1RZTEU6IG5vcm1h bDsgRk9OVC1WQVJJQU5UOiBub3JtYWw7IGZvbnQtY29sb3I6IGJsYWNrIj48Qj5EZSANCiAgOjwv Qj4gPEEgaHJlZj0ibWFpbHRvIDpvd25lci1pZXRmLXNtaW1lQG1haWwuaW1jLm9yZyI+b3duZXIt aWV0Zi1zbWltZTwvQT4gDQogIDwvRElWPg0KICA8RElWIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6 IG5vcm1hbDsgRk9OVC1TSVpFOiA5cHQ7IExJTkUtSEVJR0hUOiBub3JtYWw7IEZPTlQtU1RZTEU6 IG5vcm1hbDsgRk9OVC1WQVJJQU5UOiBub3JtYWwiPjxCPsAgDQogIDo8L0I+IDxBIA0KICBocmVm PSJtYWlsdG8gOk5pY2suUG9wZUB0aGFsZXMtZXNlY3VyaXR5LmNvbSxFU0lATElTVC5FVFNJLk9S RyxpZXRmLXNtaW1lQGltYy5vcmciPidQb3BlLE5pY2snLEVTSSxpZXRmLXNtaW1lPC9BPiANCiAg PC9ESVY+DQogIDxESVYgDQogIHN0eWxlPSJGT05ULVdFSUdIVDogbm9ybWFsOyBGT05ULVNJWkU6 IDlwdDsgTElORS1IRUlHSFQ6IG5vcm1hbDsgRk9OVC1TVFlMRTogbm9ybWFsOyBGT05ULVZBUklB TlQ6IG5vcm1hbCI+PEI+RGF0ZSANCiAgOjwvQj4gMjAwOC0wNS0yNiwgMTI6NTA6MTM8L0RJVj4N CiAgPERJViANCiAgc3R5bGU9IkZPTlQtV0VJR0hUOiBub3JtYWw7IEZPTlQtU0laRTogOXB0OyBM SU5FLUhFSUdIVDogbm9ybWFsOyBGT05ULVNUWUxFOiBub3JtYWw7IEZPTlQtVkFSSUFOVDogbm9y bWFsIj48Qj5TdWpldCANCiAgOjwvQj4gRXh0ZW5kaW5nIENBZEVTIHRvIHN1cHBvcnQgdXN1YWwg c2lnbmF0dXJlIHVwZ3JhZGluZyB0byBDQWRFUy1UIGFuZCANCiAgZnVydGhlcjwvRElWPg0KICA8 RElWPjxCUj48L0RJVj4NCiAgPERJVj48L0RJVj4NCiAgPERJVj48L0RJVj4NCiAgPERJVj4NCiAg PERJViBjbGFzcz1TZWN0aW9uMT4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4t VVM+SGVsbG8gYWxsIGFuZCBwZXJzb25hbGx5IA0KICBOaWNrLDxPOlA+PC9POlA+PC9TUEFOPjwv UD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVM+PE86UD48L086UD48L1NQ QU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUz5JbiBjdXJyZW50 IENBZEVTIHdvcmRpbmcgYSByZWd1bGFyIA0KICBzaWduYXR1cmUgd2l0aG91dCBhdCBsZWFzdCBv bmUgc2lnbmVkIGF0dHJpYnV0ZSAoU2lnbmluZyBjZXJ0aWZpY2F0ZSANCiAgcmVmZXJlbmNlKSBj YW5ub3QgYmUgYWRkZWQgd2l0aCB0aW1lc3RhbXBzIGFuZCB2YWxpZGF0aW9uIGRhdGEgdG8gYWNo aWV2ZSANCiAgQ0FkRVMtVCBvciBtb3JlIGFkdmFuY2VkIENBZEVTIHNpZ25hdHVyZS4gVGhpcyBu ZWVkIGFyaXNlcywgZS5nLiwgaW4gYSBzeXN0ZW0gDQogIHdpdGggZXhpc3RpbmcgcmVndWxhciBz aWduYXR1cmVzLiBUaGVyZSBpcyBubyBjaGFuY2UgdG8gYWRkIHRoZSByZXF1aXJlZCANCiAgYXR0 cmlidXRlIHRvIHRoZSBhbHJlYWR5IGNvbXB1dGVkIHNpZ25hdHVyZSwgYnV0IHRoZXJlIGlzIGEg c3Ryb25nIG5lZWQgdG8gYWRkIA0KICBDQWRFUyBwcm9wZXJ0aWVzIHRvIHN1Y2ggc2lnbmF0dXJl cy48TzpQPjwvTzpQPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5n PUVOLVVTPjxPOlA+PC9POlA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFO IGxhbmc9RU4tVVM+VGhlcmUgaXMgcmF0aGVyIHNpbXBsZSBhcHByb2FjaCB0byBhY2hpZXZlIA0K ICB0aGUgc2FtZSBwcm9wZXJ0aWVzIHdpdGhvdXQgaW5jbHVkaW5nIHNpZ25pbmcgY2VydGlmaWNh dGUgcmVmZXJlbmNlIGFzIGEgDQogIHNpZ25lZCBhdHRyaWJ1dGUuIExldCB1cyBpbmNsdWRlIHRo aXMgcmVmZXJlbmNlIGFzIGFuIGV4dGVuc2lvbiBpbiB0aGUgQ0FkRVMtVCANCiAgdGltZXN0YW1w IChzaWduYXR1cmUgdGltZXN0YW1wKS4gVG8gZ2V0IHN1Y2ggdGltZXN0YW1wIG9uZSB3b3VsZCBu ZWVkIHRvIA0KICBpbmNsdWRlIHRoaXMgZXh0ZW5zaW9uIGluIGEgdGltZXN0YW1wIHJlcXVlc3Qg YW5kIGEgVFNBIHdvdWxkIGhhdmUgdG8gc2hpZnQgDQogIHRoaXMgZXh0ZW5zaW9uIHRvIGEgdGlt ZXN0YW1wIHRva2VuLjxPOlA+PC9POlA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFs PjxTUEFOIGxhbmc9RU4tVVM+PE86UD48L086UD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29O b3JtYWw+PFNQQU4gbGFuZz1FTi1VUz5MZXQgdXMgZGVmaW5lIHRoZSBwcm9wb3NlZCBleHRlbnNp b24gdG8gYSANCiAgdGltZXN0YW1wIHByb3RvY29sIGFuZCBjYWxsIHRoZSBzaWduYXR1cmUgd2Ug Z2V0IGEgdmFsaWQgQ0FkRVMtVCBzaWduYXR1cmUuIA0KICBNb3JlIGFkdmFuY2VkIENBZEVTIHNp Z25hdHVyZSB0eXBlcyB0dXJuIG91dCBmcm9tIHRoaXMgbmV3IENBZEVTLVQgcGVyZmVjdGx5IA0K ICB3aXRob3V0IGFueSBtb2RpZmljYXRpb24uIFdoYXQgZG8geW91IHRoaW5rPzxPOlA+PC9POlA+ PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVM+PE86UD48 L086UD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUyBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eSI+UGF2ZWwgDQogIFNtaXJub3Y8TzpQ PjwvTzpQPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVT IA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eSI+Q3J5cHRvLVBybzxCUj5U ZWwuL0ZheDogKzcgNDk1IA0KICA3ODAtNDgyMDxCUj5XV1c6IDwvU1BBTj48QSB0aXRsZT1odHRw Oi8vd3d3LmNyeXB0b3Byby5ydS8gDQogIGhyZWY9Imh0dHA6Ly93d3cuY3J5cHRvcHJvLnJ1LyI+ PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWUi Pmh0dHA6Ly93d3cuQ3J5cHRvUHJvLnJ1PC9TUEFOPjwvQT48U1BBTiANCiAgbGFuZz1FTi1VUyBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eSI+PEJSPmUtbWFpbDogPC9TUEFOPjxB IA0KICB0aXRsZT1tYWlsdG86c3B2QENyeXB0b1Byby5ydSBocmVmPSJtYWlsdG86c3B2QENyeXB0 b1Byby5ydSI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09M T1I6IGJsdWUiPnNwdkBDcnlwdG9Qcm8ucnU8L1NQQU4+PC9BPjxTUEFOIA0KICBsYW5nPUVOLVVT PjxPOlA+PC9POlA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KbGFu Zz1FTi1VUz48TzpQPjwvTzpQPjwvU1BBTj48L1A+PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPjwv Qk9EWT48L0hUTUw+DQo= ------=_NextPart_08052614005700783103770_002-- 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 m4QAlKGZ004627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 May 2008 03:47:20 -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 m4QAlK2P004625; Mon, 26 May 2008 03:47:20 -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 mx4.cryptopro.ru (mx4.cryptopro.ru [89.221.56.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4QAlB8Q004531 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 26 May 2008 03:47:13 -0700 (MST) (envelope-from spv@cryptopro.ru) Received: from mx4.cryptopro.ru (192.168.68.5) by jake.cp.ru (192.168.68.8) with Microsoft SMTP Server id 8.1.263.0; Mon, 26 May 2008 14:50:05 +0400 Received: from smirnovxp64 ([192.168.68.187] RDNS failed) by mx4.cryptopro.ru with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 May 2008 14:50:05 +0400 From: "Pavel V. Smirnov" To: "'Pope, Nick'" , , Subject: CAdES. Storing validation data. Date: Mon, 26 May 2008 14:50:03 +0400 Message-ID: <000001c8bf1e$41ea5720$c5bf0560$@ru> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C8BF3F.C8FBF720" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aci/Hj9MN8lMCJM0TyOqb22Gph/8Bg== Content-Language: ru X-OriginalArrivalTime: 26 May 2008 10:50:05.0609 (UTC) FILETIME=[41EDD990:01C8BF1E] Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------=_NextPart_000_0001_01C8BF3F.C8FBF720 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Hello all and personally Nick, I want to draw your attention to the following problem. There is only limited possible transformation between CAdES-X Type 1 signature and CAdES-X Long Type 1 signature. Notably, one must store certificate and revocation values for signature-timestamp validation in the timestamp itself, hence, after receiving CAdES-C-timestamp one cannot add or remove these values from signature-timestamp. An obvious solution is to allow to include timestamp validation data in certificate-values and revocation-values attributes of the signature itself. What do you think? Pavel Smirnov Crypto-Pro Tel./Fax: +7 495 780-4820 WWW: http://www.CryptoPro.ru e-mail: spv@CryptoPro.ru ------=_NextPart_000_0001_01C8BF3F.C8FBF720 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

Hello all and personally = Nick,

 

I want to draw your attention to = the following problem.

 

There is only limited possible transformation between CAdES-X Type 1 signature and CAdES-X Long Type 1 signature. Notably, one must store certificate and revocation values for signature-timestamp validation in the timestamp itself, hence, after = receiving CAdES-C-timestamp one cannot add or remove these values from signature-timestamp.

 

An obvious solution is to allow = to include timestamp validation data in certificate-values and revocation-values attributes of the signature itself. What do you = think?

 

Pavel Smirnov

Crypto-Pro
Tel./Fax: +7 495 780-4820
WWW: http://www.CryptoPro.ru<= span lang=3DEN-US style=3D'font-size:10.0pt;color:navy'>
e-mail: spv@CryptoPro.ru

 

------=_NextPart_000_0001_01C8BF3F.C8FBF720-- 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 m4QAlJxd004623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 May 2008 03:47:19 -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 m4QAlJCG004622; Mon, 26 May 2008 03:47:19 -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 mx4.cryptopro.ru (mx4.cryptopro.ru [89.221.56.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4QAlFfn004586 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 26 May 2008 03:47:16 -0700 (MST) (envelope-from spv@cryptopro.ru) Received: from mx4.cryptopro.ru (192.168.68.5) by jake.cp.ru (192.168.68.8) with Microsoft SMTP Server id 8.1.263.0; Mon, 26 May 2008 14:50:15 +0400 Received: from smirnovxp64 ([192.168.68.187] RDNS failed) by mx4.cryptopro.ru with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 May 2008 14:50:15 +0400 From: "Pavel V. Smirnov" To: "'Pope, Nick'" , , Subject: Extending CAdES to support usual signature upgrading to CAdES-T and further Date: Mon, 26 May 2008 14:50:13 +0400 Message-ID: <000501c8bf1e$47cf9650$d76ec2f0$@ru> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C8BF3F.CEE13650" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aci/HkZW13VzUylGRgax42Wv2U4wnA== Content-Language: ru X-OriginalArrivalTime: 26 May 2008 10:50:15.0421 (UTC) FILETIME=[47C70AD0:01C8BF1E] Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------=_NextPart_000_0006_01C8BF3F.CEE13650 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Hello all and personally Nick, In current CAdES wording a regular signature without at least one signed attribute (Signing certificate reference) cannot be added with timestamps and validation data to achieve CAdES-T or more advanced CAdES signature. This need arises, e.g., in a system with existing regular signatures. There is no chance to add the required attribute to the already computed signature, but there is a strong need to add CAdES properties to such signatures. There is rather simple approach to achieve the same properties without including signing certificate reference as a signed attribute. Let us include this reference as an extension in the CAdES-T timestamp (signature timestamp). To get such timestamp one would need to include this extension in a timestamp request and a TSA would have to shift this extension to a timestamp token. Let us define the proposed extension to a timestamp protocol and call the signature we get a valid CAdES-T signature. More advanced CAdES signature types turn out from this new CAdES-T perfectly without any modification. What do you think? Pavel Smirnov Crypto-Pro Tel./Fax: +7 495 780-4820 WWW: http://www.CryptoPro.ru e-mail: spv@CryptoPro.ru ------=_NextPart_000_0006_01C8BF3F.CEE13650 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

Hello all and personally = Nick,

 

In current CAdES wording a = regular signature without at least one signed attribute (Signing certificate = reference) cannot be added with timestamps and validation data to achieve CAdES-T = or more advanced CAdES signature. This need arises, e.g., in a system with = existing regular signatures. There is no chance to add the required attribute to = the already computed signature, but there is a strong need to add CAdES = properties to such signatures.

 

There is rather simple approach = to achieve the same properties without including signing certificate reference as a = signed attribute. Let us include this reference as an extension in the CAdES-T timestamp (signature timestamp). To get such timestamp one would need to = include this extension in a timestamp request and a TSA would have to shift this extension to a timestamp token.

 

Let us define the proposed = extension to a timestamp protocol and call the signature we get a valid CAdES-T = signature. More advanced CAdES signature types turn out from this new CAdES-T = perfectly without any modification. What do you think?

 

Pavel Smirnov

Crypto-Pro
Tel./Fax: +7 495 780-4820
WWW: http://www.CryptoPro.ru<= span lang=3DEN-US style=3D'font-size:10.0pt;color:navy'>
e-mail: spv@CryptoPro.ru

 

------=_NextPart_000_0006_01C8BF3F.CEE13650-- 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 m4LGZLgP035705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 May 2008 09:35:21 -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 m4LGZLkL035704; Wed, 21 May 2008 09:35:21 -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 WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4LGZHZZ035658 for ; Wed, 21 May 2008 09:35:18 -0700 (MST) (envelope-from A.Hoenes@tr-sys.de) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA269547686; Wed, 21 May 2008 18:34:46 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id SAA16815 for ietf-smime@imc.org; Wed, 21 May 2008 18:34:45 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200805211634.SAA16815@TR-Sys.de> Subject: draft-ietf-smime-3851bis-02 (notes, part 2) (fwd) To: ietf-smime@imc.org Date: Wed, 21 May 2008 18:34:44 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----- Forwarded message from Alfred HÎnes ----- >From A.Hoenes@TR-Sys.de Tue May 20 16:21:51 MES 2008 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA263133310; Tue, 20 May 2008 16:21:50 +0200 Return-Path: Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id QAA14861; Tue, 20 May 2008 16:21:47 +0200 (MESZ) From: Alfred HÎnes To: blake@sendmail.com, turners@ieca.com Cc: ietf-smime@imc.org Message-Id: <200805201421.QAA14861@TR-Sys.de> Date: Tue, 20 May 2008 16:21:47 +0200 (MESZ) Subject: draft-ietf-smime-3851bis-02 (notes, part 2) Hello all, here we go with the second (and last) part of my review for draft-ietf-smime-3851bis-02 . For ease of reference, the item enumeration below extends the list from part 1 (posted yesterday). (0) Front Matter / Standards Actions The draft already indicates in its front matter: Obsoletes: 3851 During supporting investigations, it became clear that, due to specific circumstances, this will let us end up with two "valid" sets of S/MIME specifications -- those for S/MIME v3.2 and those for S/MIME v2 ! The historic reason for this scenario seems to be buried in the S/MIME v2 specifications being published as Informational RFCs and not expressly being Obsoleted by the S/MIME v3 RFCs. In Section 1.3, this draft lists RFCs 2311 through 2315 as the documents originally specifying S/MIME v2. In the RFC index, the entries for all these RFCs list INFORMATIONAL status, - RFC 2313 is tagged (Obsoleted by RFC2437), - RFC 2314 is tagged (Obsoleted by RFC2986), but - RFCs 2311, 2312, and 2315 look like being current. Arguably, it would be a matter of CMS to take action for RFC 2315, but at least RFC 2311 and RFC 2312 are clearly within scope of the S/MIME v3.2 drafts. I suggest to take the opportunity to clean up the RFC metadata and either: - also formally Obsolete the S/MIME v2 RFCs with the publication of the corresponding intended S/MIME v3.2 RFCs, (i.e. add RFC 2311 to the Obsoletes list of this draft, add RFC 2312 to the Obsoletes list of [CERT32], and defer action for RFC 2315 to CMS), or - to explicitely declare the S/MIME v2 RFCs as Historic in one place. (14) Section 2.5.3.1 The second bullet there says: - If an SMIMEEncryptionKeyPreference attribute is not found in a SignedData object received from the desired recipient, the set of X.509 certificates SHOULD be searched for a X.509 certificate | with the same subject name as the signing of a X.509 certificate ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | which can be used for key management. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I really do not understand precisely what the last two lines want to say. Please clean up and clarify. (15) Section 2.7.1.2 The visible paragraph structure there is broken; the section looks like: If the following two conditions are met: - ... - ... [[end of section]] More closely looking at the text, it turns out that fortunately the situation can be cured by inserting a paragraph break in the second bullet. For grammatical consistency, also the initial capitalization of the bullets should be changed. Thus, the section should be changed to: If the following two conditions are met: - the sending agent has no knowledge of the encryption capabilities of the recipient; and, - the sending agent has no knowledge of the version of S/MIME of the recipient, then the sending agent SHOULD use AES 128 because it is a stronger algorithm and is required by S/MIME v3.2. If the sending agent chooses not to use AES 128 in this step, it SHOULD use tripleDES. Additionally, the punctuation at the end of the first bullet now could be easily simplified: s/; and,/, and/ (16) Section 3.1 ff. -- terminological issues Being a designated Standards Track document, the draft should precisely use established IETF terminology and not occasionally fall back to common, yet sluggish (ab)use of the terms regarding the Internet message structure. Section 3.1.1 of RFC 4249 summarizes the terms established in the Internet Mail and MIME RFCs, which I will explain again in my own words: - at each conceptual protocol layer, a protocol data unit is comprised of a header and a payload (i.e., the "body" in textual protocols like email), and sometimes a trailer, as well; - the header within a protocol layer is comprised of header fields. Thus, each Internet (email) message has a single message header (Section 2.1 of I-D.2822-upd now even uses the term "message header section"). In a structured MIME message body, each nesting level has a single "MIME header", "MIME entity header", or "MIME part header" of its own (cf. RFC 2045). (We are not interested in lower level details, like MIME prologue and epilogue, etc., for the purpose of this draft.) Each message header or MIME header is comprised of header fields, with in turn consist of a field name, the colon separator, and a field value. At the MIME top level, the MIME-related header fields are integrated in the RFC[2]822 message header; they sometimes collectively are denoted as the "MIME message header". Furthermore, as explained in BCP 13, RFC 4288, the IETF should not use the popular term "MIME type", in favor of "media type". The former had not even been defined in [MIME-SPEC], and it has become even more misleading with the spread of other protocols making use of these media types. I strongly recommend to update the draft to always use this precise terminology. As a side-show, I also recommend consistently using the same spelling and capitalization for header field names -- preferably the spelling and case used in the original document defining the header field --, e.g., replace "content type" and "Content type" by "Content-Type". Because there are some subtle cases, I try to address most affected instances of these issues I found in the draft text in detail below. (17) Section 3.1 -- details (17a) 1st paragraph Applying the rationale of (16), I suggest to change (also deleting the repeated second "used" near the end of the third sentence, to streamline the language a bit): S/MIME is used to secure MIME entities. A MIME entity can be a sub- part, sub-parts of a message, or the whole message with all its sub- parts. A MIME entity that is the whole message includes only the | MIME headers and MIME body, and does not include the RFC-822 headers. ^ ^ vvvvvv ^ | Note that S/MIME can also be used to secure MIME entities used in applications other than Internet mail. If protection of the RFC-822 | headers is required, the use of the message/rfc822 MIME type is explained later in this section. --- ^^^^ S/MIME is used to secure MIME entities. A MIME entity can be a sub- part, sub-parts of a message, or the whole message with all its sub- parts. A MIME entity that is the whole message includes only the | MIME message headers and MIME body, and does not include the RFC-822 | header. Note that S/MIME can also be used to secure MIME entities in applications other than Internet mail. If protection of the RFC-822 | header is required, the use of the message/rfc822 media type is explained later in this section. (17b) 1st paragraph below 'Step 3.' Please remove the comma after "where" -- or put it in front of that "where". (17c) 2nd paragraph below 'Step 3.' Correcting a typo and applying (16), I suggest to change: | In order to protect outer, non-content related message headers (for v v ^^^^^^^ | nstance, the "Subject", "To", "From" and "CC" fields), the sending client MAY wrap a full MIME message in a message/rfc822 wrapper in | order to apply S/MIME security services to these headers. It is up ^^^^^^^ | to the receiving client to decide how to present these "inner" ^^^^^ | headers along with the unprotected "outer" headers. --- ^ ^ | In order to protect outer, non-content related message header fields | (for instance, the "Subject", "To", "From" and "Cc" fields), the sending client MAY wrap a full MIME message in a message/rfc822 | wrapper in order to apply S/MIME security services to these header | fields. It is up to the receiving client to decide how to present | this "inner" header along with the unprotected "outer" header. (18) Section 3.1.1, 2nd paragraph According to (16), please s/MIME type/media type/ (2x). (19) Section 3.1.2 According to (16): [...] If no Content-Transfer-Encoding header is present, the transfer encoding is presumed to be 7BIT. --- vvvvvv | [...] If no Content-Transfer-Encoding header field is present, the transfer encoding is presumed to be 7BIT. (20) Section 3.1.4 The legacy example of BITNET seems to be rather aged and of very low interest -- if any; cf. http://en.wikipedia.org/wiki/BITNET . I therefore suggest to simply delete " (like BITNET)" (21) Section 3.2 (21a) section title For added precision and consistency, I suggest to add "Media" in front of "Type" -- cf. 3.4.3.1, discussed in (2x) below: 3.2. The application/pkcs7-mime Type --- 3.2. The application/pkcs7-mime Media Type (21b) 3rd paragraph According to (16), please s/MIME type/media type/ (1x). (21c) last paragraph For added precision, and with respect to (16), the last sentence should be amended: | [...]. The MIME headers of all application/pkcs7-mime objects SHOULD include the optional "smime- type" parameter, as described in the following sections. --- | [...]. The Content-Type header | field of all application/pkcs7-mime objects SHOULD include the optional "smime-type" parameter, as described in the following sections. (22) Section 3.2.1, last paragraph According to (16), please s/MIME type/media type/ (1x), and s/MIME types/media types/ (1x). (23) Section 3.2.2, last numbered bullet Please correct punctuation and case: vvvv | 3. If no common string is assigned. Then the common string of "OID." is recommended (for example, "OID.1.3.6.1.5.5.7.6.1" would be DES40). --- vvv | 3. If no common string is assigned, then the common string of "OID." is recommended (for example, "OID.1.3.6.1.5.5.7.6.1" would be DES40). (24) Section 3.4.3 According to (16), please s/MIME type/media type/ (2x). (25) Section 3.4.3.1 (25a) section title With respect to (16) please change: 3.4.3.1. The application/pkcs7-signature MIME Type --- 3.4.3.1. The application/pkcs7-signature Media Type ^^^^^ (25b) 1st paragraph According to (16), please s/MIME type/media type/ (1x). (26) Section 3.4.3.2 (26a) 1st paragraph below 'Step 5' Please adjust: vv | The multipart/signed Content type has two required parameters: the protocol parameter and the micalg parameter. --- vv | The multipart/signed Content-Type has two required parameters: the protocol parameter and the micalg parameter. (26b) last paragraph: The draft says: | The SHA-224 algorithm [SHA224] and SHA-384 and SHA-512 algorithms [FIPS180-3] are not currently recommended in S/MIME, and are included here for completeness. There's an apparent disparity. SHA-224 is also covered by FIPS 180-3, and SHA-384 as well as SHA-512 are also covered by RFC 4634 not even listed as a Reference. Perhaps this has historical reasonse related to the delayed introduction of SHA-224 via a Change Notice to FIPS 180-2. Since the requirements statement is "not recommended", adding a bulk of references might be overkill; the basic Ref. should suffice. Thus, I suggest to drop [SHA224] and simplify the language: | The SHA-224, SHA-384, and SHA-512 algorithms [FIPS180-3] are not currently recommended in S/MIME, and are included here for completeness. (27) Setcion 3.9 (27a) 2nd paragraph According to (16), please change: The file suffix in the table below comes from the "name" parameter in | the content-type header, or the "filename" parameter on the content- v ^ ^ vv ^^ ^ | disposition header. These parameters that give the file suffix are not listed below as part of the parameter section. --- The file suffix in the table below comes from the "name" parameter in | the Content-Type header field, or the "filename" parameter on the | Content-Disposition header field. These parameters that give the file suffix are not listed below as part of the parameter section. (27b) table According to (16), please s/MIME type/media type/ (3x). (28) Section 4.1 The draft says: All generated key pairs MUST be generated from a good source of non- deterministic random input [RANDOM] and the private key MUST be protected in a secure fashion. IMO, this 'MUST' requirement constitutes a *Normative* Reference; so please promote '[RANDOM]' to Normative, moving the entry from B.2 to B.1. (29) Section 5 Independent on the decision to be made regarding (0) above, this section needs to be amended. (29a) Scenario 1: RFC 2311 *not* Obsoleted / made HISTORIC In this case, IANA should at least be directed to update the media type registrations for "application/pkcs7-mime" and "application/pkcs7-signature" by adding an additional reference to [RFCTHIS], in order to point the reader to the most current update of the media type information. On the other hand, updating an old media type's information arguably could require updating the registration entirely, using the new registration template from BCP 13, RFC 4288. I leave it to the high priests of exegesis (or lawyers) to figure out whether RFC 4288 in fact even normatively requests to do so. (29b) Scenario 2: RFC 2311 beinf Obsoleted or made HISTORIC In this case, the draft should substantially be amended with the two new media type registration templates, filled for both media types, "application/pkcs7-mime" and "application/pkcs7-signature", and IANA should be directed to update the registrations to incorporate this new information. (30) Section 6, 7th paragraph I suggest to make the statement on key size more specific (again, to not interfere with the future addition of other signing algorithms having other key size requirements), and to correct the placement of hyphens, as follows: Some S/MIME agents created in the United States have chosen to create | 512 bit keys in order to get more advantageous export licenses. | However, 512 bit keys are considered by many to be cryptographically insecure. --- Some S/MIME agents created in the United States have chosen to create | 512-bit RSA keys in order to get more advantageous export licenses. ^ ^^^^ v vvvv | However, 512-bit RSA keys are considered by many to be cryptographically insecure. (31) Appendix A (31a) general At first glance, it comes to surprise that there's a "~~V3dot1" ASN.1 module. For clarity, I suggest adding an introductory statement indicating that this module has been taken essentially unchanged from RFC 3851 and still applies to S/MIME v3.2. (31b) ASN.1 comment below id-cap OID definition I suggest to improve the language a bit, by inserting "OID": -- The preferBinaryInside indicates an ability to receive messages -- with binary encoding inside the CMS wrapper --- vvvvv -- The preferBinaryInside OID indicates an ability to receive -- messages with binary encoding inside the CMS wrapper. (32) Appendix B [ Interestingly, the last item for v3.2 happens to be #32 :-) ] (32a) section numbering The RFC Editor prefers References as a numbered section, not as an Appendix. Therefore, I suggest to shuffle the Appendices and turn this one into Section 7. (32b) B.1, [FIPS180-3] { oooops } vvvvvvvvvvv [FIPS180-3] "Secure Hash Signature Standard (SHS)", National Institute of Standards and Technology (NIST). FIPS Publication 180-3. --- | [FIPS180-3] "Secure Hash Standard (SHS)", National Institute of Standards and Technology (NIST), FIPS Publication | 180-3, June 2007. ^^^^^^^^^^^ or better, listing the source first (as also done for ITU-T documents): | [FIPS180-3] National Institute of Standards and Technology (NIST), | "Secure Hash Standard (SHS)", FIPS Publication 180-3, | June 2007. (32c) B.2, [RANDOM] Please add "BCP 106, " in front of "RFC 4086". regarding eventual promotion to Normative, please see item (28) above. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ ----- End of forwarded message from Alfred HÎnes ----- 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 m4LGYuFp035500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 May 2008 09:34:56 -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 m4LGYuLU035498; Wed, 21 May 2008 09:34:56 -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 WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4LGYrfM035490 for ; Wed, 21 May 2008 09:34:54 -0700 (MST) (envelope-from A.Hoenes@tr-sys.de) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA269517662; Wed, 21 May 2008 18:34:22 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id SAA16809 for ietf-smime@imc.org; Wed, 21 May 2008 18:34:21 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200805211634.SAA16809@TR-Sys.de> Subject: draft-ietf-smime-3851bis-02 (notes, part 1) (fwd) To: ietf-smime@imc.org Date: Wed, 21 May 2008 18:34:21 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----- Forwarded message from Alfred HÎnes ----- >From A.Hoenes@TR-Sys.de Mon May 19 11:21:42 MES 2008 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA254648901; Mon, 19 May 2008 11:21:41 +0200 Return-Path: Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id LAA12918; Mon, 19 May 2008 11:21:38 +0200 (MESZ) From: Alfred HÎnes To: blake@sendmail.com, turners@ieca.com Cc: ietf-smime@imc.org Message-Id: <200805190921.LAA12918@TR-Sys.de> Date: Mon, 19 May 2008 11:21:38 +0200 (MESZ) Subject: draft-ietf-smime-3851bis-02 (notes, part 1) Hello, I would like to also submit a few comments on your Internet-Draft, draft-ietf-smime-3851bis-02. Due to time constraints, I have decided to split the intended comments. This is the first part addressing the initial sections of the draft, up to section 2.5.1; more will follow ASAP. (1) Conventions used ... - The RFC Editor will want to make that a proper (numbered) section. I suggest to move it to between the current sub-sections 1.1 and 1.2. - The comments I sent on the same part of draft-ietf-smime-3850bis-02 also apply. (2) Section 1 (2a) 1st paragraph For completeness (and matching of what is said in the Abtract), I suggest to add a short note on message compression to the end of the first paragraph of Section 1, for instance: As a supplementary service, S/MIME provides for message compression. (2b) 2nd paragraph Perhaps the most important usage scenario for S/MIME now is bound to SIP (using the 'sips' URIs) to protect the negotioation of multimedia session parameters (cf. RFC 3261). Therefore, I suggest to replace in the second paragraph of Section 1 the clause "such as HTTP" by "such as HTTP or SIP". (3) General -- terminology It has been generally recognized that the media type concept defined in [MIME-SPEC] has outgrown the narrow context of MIME, and RFC 4288 (BCP 13) has confirmed that the popular sluggish term "MIME Type" should not be used, in favor of the proper term "Media Type", which already had been used throughout [MIME-SPEC]. Therefore, I recommend to also change in this draft all occurrences of "MIME type" to "media type" (inclusive of the title of Section 3.4.3.1). Also, when refering to MIME header fields, their names should be quoted faithfully for clarity and precision; in particular, the hyphen should always be included after "Content", e.g., "Content type" --> "Content-type". (4) Section 1.1 (4a) 1st paragraph The draft says: This document describes a protocol for adding cryptographic signature and encryption services to MIME data. The MIME standard [MIME-SPEC] | provides a general structure for the content type of Internet | messages and allows extensions for new content type applications. There are two issues with the use of "content type": - "structure of the content type" is a slight abuse of language; "structure of content" is the proper designation. - "content type applications" seems to be vague and unclear. I suggest to use "content type specific applications" or "content type based applications" instead (4b) 2ns and 3rd paragraph Please apply (3) -- 3 occurrences. (5) Section 1.3 For clarity, please add another comma after the first instance of "inclusive", or place this word in parentheses. (6) Section 1.4 (6a) section title The legacy section title obviously is outdated, turning it ambiguous. It should better be changed: 1.4. Changes Since S/MIME v3 --- | 1.4. Changes From S/MIME v3 to S/MIME v3.1 This should properly complement the correctly entitled new section, 1.5. Changes Since S/MIME v3.1 (6b) last two paragraphs Please apply (3) -- two occurrences. (7) Section 1.5 -- typo Please replace "in parantheticals" by either "parenthetical" or "in parenthesis". (7) Section 1.5 -- typo Please replace vv v "AES-CBC" in parantheticals. by either: parenthetical "AES-CBC". or: parenthetic "AES-CBC". or: "AES-CBC" in parenthesis. (8) Section 2 -- clarification of the role of [ESS] I suggest to add a note to the text in Section 2 clarifying that RFC 2634 [ESS] is applicable for S/MIME v3.2 as well. This is intended to complement the remarks in Section 1.3 stating that RFC 2634 is part of the S/MIME v3 and S/MIME v3.1 specification. (9) Section 2.3 Please replace using rsaEncryption algorithm. by either: using the rsaEncryption algorithm. or: using rsaEncryption. (10) Section 2.4.1 The draft says: vvvvvvvvvvvv ... the MIME content MUST be stored in the SignedData encapContentInfo eContent OCTET STRING ... This is misleading; the Content-Type has to be stored there, not the "content". In line with (3) above, I suggest to use the phrase: vvvvvvvvvvv | ... the media type MUST be stored in the SignedData encapContentInfo eContent OCTET STRING ... (11) Section 2.4.4, 1st paragraph I suggest to insert the article "the" giving "reduce the message size". (12) Section 2.5 (12a) 1st paragraph The draft says, using redundant/replicated wording: vvvvvvvvvvvvv The SignerInfo type allows the inclusion of unsigned and signed attributes to be included along with a signature. ^^^^^^^^^^^^^^ I suggest to simplify the wording to: The SignerInfo type allows the inclusion of unsigned and signed | attributes along with a signature. ^ (12b) 2nd-to-last paragraph The draft says: [..]. Receiving agents SHOULD handle attributes or values that it does not recognize in a graceful manner. The wording "receiving agents ... it does not" should be improved upon. I suggest either to turn to singular: vv vv | [..]. A Receiving agent SHOULD handle attributes or values that it does not recognize in a graceful manner. or substitute "they" in the last line: [..]. Receiving agents SHOULD handle attributes or | values they do not recognize in a graceful manner. ^^^^^^^ (13) Section 2.5.1 The rules for UTCTime vs. GeneralizedTime are unfortunate for several reasons, as I have pointed out in recent comments on RFC 5280. They violate the lessons learned during Y2K that 4 decimal digits should *always* be encoded for year numbers, and they cause general non-exercising of 'MUST implement' code, generating a new security risk. I strongly recommend to, at a minimum, demote the "MUST" to encode signing-time through 2049 as UTCTime to a "MUST-", preferably "SHOULD", to promote starting general migration to GeneralizedTime. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ ----- End of forwarded message from Alfred HÎnes ----- 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 m4LGYfeo035404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 May 2008 09:34:41 -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 m4LGYffm035402; Wed, 21 May 2008 09:34:41 -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 WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4LGYc6K035369 for ; Wed, 21 May 2008 09:34:40 -0700 (MST) (envelope-from A.Hoenes@tr-sys.de) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA269487646; Wed, 21 May 2008 18:34:06 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id SAA16803 for ietf-smime@imc.org; Wed, 21 May 2008 18:34:05 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200805211634.SAA16803@TR-Sys.de> Subject: draft-ietf-smime-3850bis-02 (fwd) To: ietf-smime@imc.org Date: Wed, 21 May 2008 18:34:04 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----- Forwarded message from Alfred HÎnes ----- >From A.Hoenes@TR-Sys.de Sun May 18 16:37:14 MES 2008 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA250571434; Sun, 18 May 2008 16:37:14 +0200 Return-Path: Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id QAA11896; Sun, 18 May 2008 16:37:12 +0200 (MESZ) From: Alfred HÎnes To: blake@sendmail.com, turners@ieca.com Message-Id: <200805181437.QAA11896@TR-Sys.de> Date: Sun, 18 May 2008 16:37:12 +0200 (MESZ) Subject: draft-ietf-smime-3850bis-02 Hello, I'd like to also submit a few comments on your I-D, draft-ietf-smime-3850bis-02. (1) Conventions used ... a) I have not followed the progress of draft-hoffman-additional-key-words, but it looks like the evolution of that document might be worth being monitored or coordinated with, in order to avoid repeated re-specification of the new keywords. b) last paragraph: MUST- This term means the same as MUST. However, we expect at some point that this algorithm will no longer be a MUST in a future document. [...] I'd give preference to the word-shuffled variant: | MUST- This term means the same as MUST. However, we expect that at | some point this algorithm will no longer be a MUST in a future document. [...] (2) Section 2.2 Without explanation, the draft says: Receiving agents MUST support v1 X.509 and v3 X.509 identity certificates as profiled in [KEYM]. [...] This comes to surprise. Why are v2 certificates excluded? The deliberations in RFC 5280 seem to make v1 much less preferable. If there ideed are reasons for this particular requirement, a hint on the rationale would be useful. (3) Section 3 Below the ASN.1 fragment, please s/an upper bounds/an upper bound/ ^ (4) Section 4.3 The last paragraph says: A receiving agent MUST be capable of verifying the signatures on certificates and CRLs with key sizes from 512 bits to 2048 bits. This requirement seems to be taylored to RSA/DSA key sizes, but possibly not appropriate for the developing ECDSA context. To not inappropriately exclude shorter ECDSA key sizes and request support for unusually large ECDSA key sizes, the above statement should perhaps be restricted in scope. Matching the algorithm support requirements in the earlier parts of 4.3, but not precluding future more previce specification of ECDSA use with PKIX, CMS, and S/MIME, I propose to amend the above statement to say: vvvvvvvvvvvvv | A receiving agent MUST be capable of verifying RSA and DSA signatures on certificates and CRLs with key sizes from 512 bits to 2048 bits. (5) Sections 6 The lenghty deliberations on MD2 in this section seem to be aged, or almost historical now. Shouldn't there be some words pointing out more recent developments, in particular the perceived issues with / reduced confidence in MD5 (and perhaps also SHA-1) as well? (6) Appendix A It is very unusual to label these sections "Appendix". I suggest to renumber "Appendix A" to "Section 7". "[RFC-2822]" is the only ref. tag used incorporating an RFC number. I do not know the planned schedule, but it might happen that 2822-upd will be faster on the publication track, making a ref. update necessary. To prepare for it, and to arrive at a more homogenous ref. tag style, I suggest replacing "[RFC-2822]" by "[IMF]". For clerical completeness, I note the race condition that has occurred by nearly concurrent publication events, making the draft miss the ref. update: [KEYM] --> RFC 5280. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ ----- End of forwarded message from Alfred HÎnes ----- 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 m4E6b8lW001590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 23:37: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 m4E6b8Zw001589; Tue, 13 May 2008 23:37: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 mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4E6a6Hk001494; Tue, 13 May 2008 23:36:37 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 157FA184EC; Wed, 14 May 2008 18:36:02 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfsIQf72dlg2; Wed, 14 May 2008 18:36:01 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id EC7DA184E9; Wed, 14 May 2008 18:36:01 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id C37A819EC0BA; Wed, 14 May 2008 18:35:56 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JwAai-0007K9-L7; Wed, 14 May 2008 18:35:56 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, phoffman@imc.org Subject: Re: S/MIME v3.2 IDs key size text Cc: ietf-smime@imc.org In-Reply-To: Message-Id: Date: Wed, 14 May 2008 18:35:56 +1200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul Hoffman writes: >...and none of these relate to the S/MIME standard, right? Uhh, my posting specifically mentioned PKCS #7 signing (you actually quote the sentence right below the above comment), which the last time I checked was still S/MIME. >>How many would you like? >Only real ones that relate to this thread, thank you. Geeze, how many do you want me to dig up? The three I mentioned are ones readily to hand and ones where I knew I could mention them (in anonymised form), I'd have to ask about posting some of the others (and also spend way more time than it's worth digging through old email to locate them). In any case here's another one, from some years ago, again PKCS #7 (although PKCS #7 could probably be valid today as well, some places still don't know there's something called CMS). Anyway, some folks were using 256-bit RSA keys to send signed EDI messages around wrapped in PKCS #7 envelopes. The reason they used these was because their application, written by some contractor in Java [0], ran really slowly and their security guy [1] told them that the performance problems were because of the RSA key size being used, which was initially 1K bits (it had nothing to do with the fact that it was written in Java, it was purely the RSA key size's fault). Since they were using keys twice as large as the industry standard 128 bits and everyone knew 128 bits was totally secure, they were perfectly OK. >If you have actual quotes of people saying that, fine; quoting someone third- >hand through an IETF security geek is not a good way to get accurate results. It wasn't third-hand, it was either from me if I was involved in the work or from the person who was involved if it wasn't me [2]. In the above case (which I was directly involved with) "the standard doesn't disallow it" was the argument given for using the 256-bit keys, some mere coders tried to point out that this was wrong and the response was that there was nothing in the standard so say it was wrong and anyway the contractors had already spent X amount of time on it so unless anyone could come up with a good reason not to, it was being deployed with 256-bit RSA signatures. And so it went. Peter. [0] This was before things like Bouncy Castle were freely available and people had to build higher-level protocols from raw JCE parts with their own three hands. [1] He'd read the first two chapters of Applied Crypto. [2] Or are you saying that other members of this list, who provided some of the information, aren't reliable sources? Is there a vetting procedure they're supposed to go through first? Shall I ask for affidavits? 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 m4DJIodR092153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 12:19:11 -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 m4DJIoZ3092152; Tue, 13 May 2008 12:18: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] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4DJIPdj092097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 12:18:25 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 13 May 2008 12:18:23 -0700 To: Luther Martin , Peter Gutmann From: Paul Hoffman Subject: RE: S/MIME v3.2 IDs key size text Cc: "ietf-smime@imc.org" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:47 AM -0700 5/13/08, Luther Martin wrote: > > -----Original Message----- > > From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] > > On Behalf Of Paul Hoffman > > >In the > > >case of two of the three above the justification given was some variation > > on > > >"if these really were no good then they'd be explicitly disallowed. > > Since > > >they aren't, it's perfectly OK to do this". > > > > I'm skeptical, to say the least. If you have actual quotes of people > > saying that, fine; quoting someone third-hand through an IETF > > security geek is not a good way to get accurate results. > >I'm with Peter on this one. > >I don't want to try to one-up Peter's stories (although I might be >able to), I've also seen all sorts of blunders caused by people >unfamiliar with public-key technology not understanding things that >everyone on this list almost certainly takes for granted. I'd guess >that most people who have worked with users of public-key technology >for any length of time have a similar set of stories. Of course this is true. What I question is Peter's assertion that putting a "don't be stupid" clause in the S/MIME RFC will cause any of them to be less stupid. In order to believe that, I want to hear someone say "I read the RFC and I still made this decision". I doubt that is true because I doubt any of these folks read the RFC. >I've also seen people wanting to do make all sorts of >crypto-blunders to make things easier to use, more efficient, or to >comply with the letter of regulations instead of the spirit. > >So explicitly banning things that might qualify as such blunders is >probably a very good idea. Maybe so, but that's not what Peter was advocating. I'm pretty sure he was supporting a statement that applications MUST NOT validate signatures that are 511 bits long while allow applications to validate signatures that are 512 bits long. 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 m4DHvs5C082284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 10:57:59 -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 m4DHvsvg082283; Tue, 13 May 2008 10:57:54 -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 ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4DHvN65082230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 13 May 2008 10:57:54 -0700 (MST) (envelope-from blake@sendmail.com) Received: from spork.sendmail.com (tls.sendmail.com [209.246.26.41]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id m4DI0JDp015059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 13 May 2008 11:00:19 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1210701619; bh=FH2Y957tO6NjlIoiZae221nwDz8yazYs1V6m 4dcfdsk=; h=Received:X-DKIM:DKIM-Signature:Date:From:To:Subject: Message-ID:MIME-Version:Content-Type:Content-Disposition: User-Agent:X-MM-Ex-RefId; b=LsCO1F5MDUN5NexfozscWN2JJe14H3LeWxtZcL B8H9PvXNtbYdf2Zsfd5VWh4m8hfOnVlq1/DMnhrodC+HHnEQ3lBS+pd3FaFA1NOqaNF fgZxMfGW6DwvkVoNCzEWh6s8WbIrk9yIAZbEvR0JevKwBxx7uCLrKh/dIYzC+SdgM4= Received: from dell-desktop.example.com (c-24-17-217-200.hsd1.mn.comcast.net [24.17.217.200]) (authenticated bits=0) by spork.sendmail.com (Switch-3.3.1/Switch-3.3.2mp) with ESMTP id m4DHv6w0011254 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 13 May 2008 10:57:14 -0700 X-DKIM: Sendmail DKIM Filter v2.2.3 spork.sendmail.com m4DHv6w0011254 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=spork.dkim; t=1210701436; bh=FH2Y957tO6NjlIoiZae221nwDz8yazYs1V6m 4dcfdsk=; h=Date:From:To:Subject:Message-ID:MIME-Version: Content-Type:Content-Disposition:User-Agent:X-MM-Ex-RefId; b=f0YB6 gK7E7GvLC0mc5H0wBFsxlsSgZbOXqyPoI8vjnoJGYsjJFgY1m2hZt8tB3bN7VW5tUaF 5JNG8U7wkiYDkJ2U8MO9P0ClFB5pNFyFzGCCa5ZVKbR3tAUeQgLHJG+q/1zUcwe2dDz dPOcsKdvNwqzILI5aN2JtYWcsomemH5M= Date: Tue, 13 May 2008 10:57:06 -0700 From: Blake Ramsdell To: ietf-smime@imc.org Subject: [CAT HERDING] Key lengths for interoperability and security considerations Message-ID: <20080513175705.GA6177@dell-desktop.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-MM-Ex-RefId: 149371::080513105715-1AEDFB90-2DC85328/0-0/0-1 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: OK, so what needs to be done to come to closure on the key sizes. I think a skeleton of The Right Thing looks something like this: 1. Normative language (MUST / SHOULD with lots of plusses and minuses and atsigns) describing the minimum and maximum lengths for keys. This covers the most important area of interoperability, and needs to be very clear about signing key lengths vs. verifying key lengths vs. generating key lengths. 2. An indication by those MUST / SHOULD statements pointing to the security considerations. This is the best we can do to guide people away from using one bit keys, and steer them in the direction of strong crypto. 3. Wording in the security considerations regarding the use of overshort or overlong keys. Sean is preparing a summary of the existing discussion to address each point, and we'll see where we're at. Blake 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 m4DHnDBm081191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 10:49:43 -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 m4DHnDn5081190; Tue, 13 May 2008 10:49: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 mail.voltage.com (mail.voltage.com [209.213.222.98]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4DHmBLc081066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 10:48:42 -0700 (MST) (envelope-from martin@voltage.com) Received: from hqmailsvr01.voltage.com (hqmailsvr01.voltage.com [172.16.0.22]) by mail.voltage.com (8.13.7/8.13.7) with ESMTP id m4DHmLOq025020 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 13 May 2008 10:48:21 -0700 Received: from hqmailsvr01.voltage.com ([172.16.0.22]) by hqmailsvr01.voltage.com ([172.16.0.22]) with mapi; Tue, 13 May 2008 10:48:00 -0700 From: Luther Martin To: "'Paul Hoffman'" , Peter Gutmann CC: "ietf-smime@imc.org" Date: Tue, 13 May 2008 10:47:59 -0700 Subject: RE: S/MIME v3.2 IDs key size text Thread-Topic: S/MIME v3.2 IDs key size text Thread-Index: Aci1Gqm7dlm/uVg0RkaxGp5uBy4bOwAAxxog Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B870629719727B4BA82A6C06A31C291203064022F4hqmailsvr01vo_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=4.65.7161:2.4.4,1.2.40,4.0.164 definitions=2008-05-13_06:2008-05-13,2008-05-13,2008-05-13 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=3.1.0-0804140000 definitions=main-0805130118 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_000_B870629719727B4BA82A6C06A31C291203064022F4hqmailsvr01vo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org= ] > On Behalf Of Paul Hoffman > >In the > >case of two of the three above the justification given was some variatio= n > on > >"if these really were no good then they'd be explicitly disallowed. > Since > >they aren't, it's perfectly OK to do this". > > I'm skeptical, to say the least. If you have actual quotes of people > saying that, fine; quoting someone third-hand through an IETF > security geek is not a good way to get accurate results. I'm with Peter on this one. I don't want to try to one-up Peter's stories (although I might be able to)= , I've also seen all sorts of blunders caused by people unfamiliar with pub= lic-key technology not understanding things that everyone on this list almo= st certainly takes for granted. I'd guess that most people who have worked = with users of public-key technology for any length of time have a similar s= et of stories. I've also seen people wanting to do make all sorts of crypto-blunders to ma= ke things easier to use, more efficient, or to comply with the letter of re= gulations instead of the spirit. So explicitly banning things that might qualify as such blunders is probabl= y a very good idea. --_000_B870629719727B4BA82A6C06A31C291203064022F4hqmailsvr01vo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> -----Original Message-----

> From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org]

> On Behalf Of Paul Hoffman

> >In the

> >case of two of the three above the justification given was some variation

> on

> >"if these really were no good then they'd be explicit= ly disallowed.

> Since

> >they aren't, it's perfectly OK to do this".

>

> I'm skeptical, to say the least. If you have actual quotes of people

> saying that, fine; quoting someone third-hand through an IETF<= o:p>

> security geek is not a good way to get accurate results.<= /o:p>

 

I'm with Peter on this one.

 

I don't want to try to one-up Peter's stories (although I might be = able to), I've also seen all sorts of blunders caused by people unfamiliar with public-key technology not understanding things that everyone on this list a= lmost certainly takes for granted. I'd guess that most people who have worked wit= h users of public-key technology for any length of time have a similar set of stories.

 

I've also seen people wanting to do make all sorts of crypto-blunde= rs to make things easier to use, more efficient, or to comply with the letter = of regulations instead of the spirit.

 

So explicitly banning things that might qualify as such blunders is probably a very good idea.

--_000_B870629719727B4BA82A6C06A31C291203064022F4hqmailsvr01vo_-- 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 m4DG9pTQ068334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 09:09:57 -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 m4DG9pSe068333; Tue, 13 May 2008 09:09: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 m4DG9m9Q068318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 May 2008 09:09:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 13 May 2008 09:09:46 -0700 To: ietf-smime@imc.org From: Internet-Drafts@ietf.org (by way of Paul Hoffman) Subject: I-D ACTION:draft-ietf-smime-3851bis-02.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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-02.txt Pages : 40 Date : 2008-5-12 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-02.txt 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 m4DG9oX0068327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 09:09:57 -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 m4DG9o8q068326; Tue, 13 May 2008 09:09: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 m4DG9m9O068318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 May 2008 09:09:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 13 May 2008 09:09:26 -0700 To: ietf-smime@imc.org From: Internet-Drafts@ietf.org (by way of Paul Hoffman) Subject: I-D ACTION:draft-ietf-smime-3850bis-02.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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-02.txt Pages : 18 Date : 2008-5-12 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-02.txt 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 m4DG95FY068233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 09:09:27 -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 m4DG95Pw068232; Tue, 13 May 2008 09:09:05 -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 m4DG8jh1068155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 09:08:47 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 13 May 2008 09:08:43 -0700 To: pgut001@cs.auckland.ac.nz (Peter Gutmann) From: Paul Hoffman Subject: Re: S/MIME v3.2 IDs key size text Cc: ietf-smime@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 6:50 PM +1200 5/13/08, Peter Gutmann wrote: >Paul Hoffman writes: > >>You'll need to justify this one, Peter. Show me some examples where any >>previous version of S/MIME, none of which have "sane" lower limits, was used >>by any organization to justify a stupid key size. > >How many would you like? Only real ones that relate to this thread, thank you. >Without naming names (if anyone really insists I >could perhaps name them in private), there's an organisation using 128-bit RSA >keys for access control to significant amounts of power switching gear because >everyone knows that 128-bit keys are good so it should be fine for RSA. Since >this is in the US I'm not that fussed about someone using it to take out their >power transmission systems :-), but I think some other people might be. Uhh, >Canadian health board using RSA in ECB mode to encrypt patient data, and they >ended up using either 128- or 64-bit keys because otherwise things ran too >slowly. Signing using 384-bit keys by a european government organisation... >how many do you want, and how long have you got? I haven't got them all >committed to memory so I'd have to dig back through old email and whatnot. ...and none of these relate to the S/MIME standard, right? >I realise these aren't all specificially for S/MIME (the signing one was, at >least for PKCS #7) but they're examples of just what people will do if the >standards don't disallow it. I'll take that as a "right, they don't relate to the S/MIME standard, they're general key-size blunders". That is, the current S/MIME standard mandates being able to sign with 512-bit keys, but your examples above show that the blunderers don't do that. Please explain why you think that changing the standard will have any effect on them at all. >A number of the examples came from talking to >other IETF security folks so there's probably a lot more like this floating >around (every time I post one of these horror-story comments I tend to get a >bunch of email saying "That's nothing, you should hear this one..."). Fully agree. >In the >case of two of the three above the justification given was some variation on >"if these really were no good then they'd be explicitly disallowed. Since >they aren't, it's perfectly OK to do this". I'm skeptical, to say the least. If you have actual quotes of people saying that, fine; quoting someone third-hand through an IETF security geek is not a good way to get accurate results. > >Please suggest specific text that would meet your criteria. > >The original (proposed) MUST NOT text. There was no verb in that text. Are you supporting "MUST NOT sign with keys under 512 bits", "MUST NOT verify signatures whose keys are under 512 bits", or both? >There's no point in verifying a >signature that you know is insecure because you know no more about the >validity of the data after the verification than you did before. Fully agree. Please say why you know that every signature with keys of 511 bits is insecure, yet ones with 512 bits are secure enough. >If the >signature can't tell you anything about the validity of the data that's been >signed then it should be rejected as an invalid signature because it's not >serving the purpose for which it was intended. Fully agree. 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 m4D6pExg081412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 23:51:20 -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 m4D6pEcm081411; Mon, 12 May 2008 23:51: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 mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4D6oCkk081275; Mon, 12 May 2008 23:50:43 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2627E48067D; Tue, 13 May 2008 18:50:10 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZdnB-R-DTxq; Tue, 13 May 2008 18:50:10 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 0C4FE48067B; Tue, 13 May 2008 18:50:09 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id B4AC419EC0BA; Tue, 13 May 2008 18:50:02 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JvoKo-0004wr-Ir; Tue, 13 May 2008 18:50:02 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, phoffman@imc.org Subject: Re: S/MIME v3.2 IDs key size text Cc: ietf-smime@imc.org In-Reply-To: Message-Id: Date: Tue, 13 May 2008 18:50:02 +1200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul Hoffman writes: >You'll need to justify this one, Peter. Show me some examples where any >previous version of S/MIME, none of which have "sane" lower limits, was used >by any organization to justify a stupid key size. How many would you like? Without naming names (if anyone really insists I could perhaps name them in private), there's an organisation using 128-bit RSA keys for access control to significant amounts of power switching gear because everyone knows that 128-bit keys are good so it should be fine for RSA. Since this is in the US I'm not that fussed about someone using it to take out their power transmission systems :-), but I think some other people might be. Uhh, Canadian health board using RSA in ECB mode to encrypt patient data, and they ended up using either 128- or 64-bit keys because otherwise things ran too slowly. Signing using 384-bit keys by a european government organisation... how many do you want, and how long have you got? I haven't got them all committed to memory so I'd have to dig back through old email and whatnot. I realise these aren't all specificially for S/MIME (the signing one was, at least for PKCS #7) but they're examples of just what people will do if the standards don't disallow it. A number of the examples came from talking to other IETF security folks so there's probably a lot more like this floating around (every time I post one of these horror-story comments I tend to get a bunch of email saying "That's nothing, you should hear this one..."). In the case of two of the three above the justification given was some variation on "if these really were no good then they'd be explicitly disallowed. Since they aren't, it's perfectly OK to do this". >Please suggest specific text that would meet your criteria. The original (proposed) MUST NOT text. There's no point in verifying a signature that you know is insecure because you know no more about the validity of the data after the verification than you did before. If the signature can't tell you anything about the validity of the data that's been signed then it should be rejected as an invalid signature because it's not serving the purpose for which it was intended. Peter. 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 m4CMr4Y3060706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 15:53:04 -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 m4CMr48C060705; Mon, 12 May 2008 15:53:04 -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.200] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4CMr1H2060694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 15:53:02 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <004c01c8b44b$328b0e60$02b5a8c0@tony> Date: Mon, 12 May 2008 15:20:31 -0700 To: "Turner, Sean P." From: Paul Hoffman Subject: RE: S/MIME v3.2 IDs key size text (resend, no signature) 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:57 PM -0400 5/12/08, Turner, Sean P. wrote: > >-----Original Message----- >>From: owner-ietf-smime@mail.imc.org >>[mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Paul Hoffman >>Sent: Monday, May 12, 2008 12:49 PM >>To: Tony Capel >>Cc: ietf-smime@imc.org >>Subject: RE: S/MIME v3.2 IDs key size text (resend, no signature) >> >> >>At 12:14 PM -0400 5/12/08, Tony Capel wrote: >>>Sean et al: >>> >>>How about: >>> >>> 0 < key size < 512 : MAY but refer to security >>considerations >>>section >>> 512 <= key size < 1024 : SHOULD- but refer to security >>considerations >>>section >>>1024 <= key size <= 2048 : MUST >>>2048 < key size : MAY but refer to security >>considerations >>>section >> >>Could you add verbs to your table? MAY what? SHOULD- what? > >Not sure what Tony was thinking but I suggested that this go in 3850bis so >it would have been for receiving agents. In your mind, what verb goes with "SHOULD-" for a receiving agent? "SHOULD be able to verify but we won't require it in a future version"? If so, that means that we are saying "we intend to break interoperability with previous versions of this spec because of security issues". Breaking the implied stability promise we made when there is no real threat (such as people forging 768-bit signatures) seems a bit over the top. Further, such an interpretation of SHOULD- also means that we intend to deprecate 1024 bit keys in the foreseeable future even though the cryptographic security of >90% of Internet commerce is based on those keys. If the intention was to get implementers to take us seriously, saying this may not have the desired effect. 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 m4CLw7Vc048979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 14:58: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 m4CLw7c4048978; Mon, 12 May 2008 14:58: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 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 m4CLw5Ua048935 for ; Mon, 12 May 2008 14:58:06 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 18011 invoked from network); 12 May 2008 21:58:02 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.241.98.201 with login) by smtp106.biz.mail.re2.yahoo.com with SMTP; 12 May 2008 21:58:02 -0000 X-YMail-OSG: dpPPwCEVM1kxzmWd_uhpL5tPptarikE.d9AtlaWcSmY.6bDWpt62pnlyTbTYF1Bzb8fhd6rAe9o4jGAzsuvMqElsj6kA6QWTXPuHR7rkmzuQ5E.wB3BA7Eoa1JzeLQBpLDU- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "'Paul Hoffman'" , "'Tony Capel'" Cc: References: <004c01c8b44b$328b0e60$02b5a8c0@tony> Subject: RE: S/MIME v3.2 IDs key size text (resend, no signature) Date: Mon, 12 May 2008 17:57:54 -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 Thread-Index: Aci0W1KMBL1FF82SRbyczeTB2B84vQABIndg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: 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: Monday, May 12, 2008 12:49 PM >To: Tony Capel >Cc: ietf-smime@imc.org >Subject: RE: S/MIME v3.2 IDs key size text (resend, no signature) > > >At 12:14 PM -0400 5/12/08, Tony Capel wrote: >>Sean et al: >> >>How about: >> >> 0 < key size < 512 : MAY but refer to security >considerations >>section >> 512 <= key size < 1024 : SHOULD- but refer to security >considerations >>section >>1024 <= key size <= 2048 : MUST >>2048 < key size : MAY but refer to security >considerations >>section > >Could you add verbs to your table? MAY what? SHOULD- what? Not sure what Tony was thinking but I suggested that this go in 3850bis so it would have been for receiving agents. >>"A denial of service opportunity may exploitable by attackers who >>provide an excessively large key, or a key selected to require >>excessive cryptographic processing. One mitigation approach would >>require that the corresponding public key certificate be >validated to a >>trusted root [trust anchor] prior to use, thus ensuring that only >>trusted public keys are used. However, some implementations >may choose >>to perform signature verification (or data encryption) in >parallel with >>certificate validation, or 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." > >Regardless of small key size issue, I think text like this >would be a good addition to the Security Considerations >section of many documents. I had something similar in the -02 version, but I'll swap out that text for this text. 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 m4CLQZLd036227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 14:26:35 -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 m4CLQZeI036225; Mon, 12 May 2008 14:26:35 -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] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4CLQWIj036198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 14:26:34 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <93A6E28F-962E-4D08-B671-D66EB226AADC@mitre.org> References: <004c01c8b44b$328b0e60$02b5a8c0@tony> <58461908-4572-411C-AFD5-BE8BF8A5E5FD@mitre.org> <93A6E28F-962E-4D08-B671-D66EB226AADC@mitre.org> Date: Mon, 12 May 2008 14:25:34 -0700 To: Timothy J Miller From: Paul Hoffman Subject: Re: S/MIME v3.2 IDs key size text (resend, no signature) 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 3:51 PM -0500 5/12/08, Timothy J Miller wrote: >On May 12, 2008, at 3:19 PM, Paul Hoffman wrote: > >>Only somewhat similar. Tony's proposed changes has a "SHOULD >>inform" and a "SHOULD provide a warning". The quoted test is >>"SHOULD provide alternate processing" which may be displaying a >>message. That's a big difference. > >Yet the very next paragraph says: > >""" >A receiving agent SHOULD display a subject name or other certificate >details when displaying an indication of successful or unsuccessful >signature verification. >""" > >Sounds the same to me. Reading that quoted sentence, can you see that the "SHOULD" does not apply when not "displaying an indication..."? That sentence does not mandate showing anything. If there is something in an S/MIME document that mandates "showing" or "warning", it is an error. We spent years (well, now a decade) working on this so that a conformant implementation does not need to have a UI. >Here's the thing: You're advocating interpreting the spec as purely >a protocol spec. If that's what you're after, then that's a bigger >issue than trading barbs over key length recommendations. There are >a number of clauses that require UI implementation that need to be >struck out (or at least moved to the security considerations >section). Struck out, definitely. By all means point them out. I've read this too many times to find them, I guess. >But here's my problem with that thinking: S/MIME isn't just a >protocol, it's a ceremony. There's an fundamental UI aspect to >ceremonies. I disagree strongly with the former while agreeing strongly with the latter. >This needs to be dealt with properly and *prominently* or we'll end >up with implementations that don't just *allow* bad things to be >done, but that *mislead users* into thinking things are true about >messages that just aren't. That "misleading" will happen regardless of what the spec says. It already happens now, and it happened before the IETF took over S/MIME. And it's not just S/MIME: nearly every security protocol the IETF has developed has the same problem. It's in the nature of security and users and vendors. If you want to write a BCP for implementers, that's great. This mailing list would be a great place for it to be discussed. This spec is not a BCP: it is a standard that needs to be consistent on both interoperability and security. >Moving all UI-related issues or security related recommendations to >a separate section lowers their visibility, and that's not a good >thing IMHO. It definitely lowers their visibility, and it's also the way we usually do things in the IETF. We've done it for over a decade for much higher-profile security protocols such as TLS and IPsec as well. 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 m4CLF3aI032301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 14:15: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 m4CLF36r032299; Mon, 12 May 2008 14:15: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 [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4CLF2EB032269 for ; Mon, 12 May 2008 14:15:02 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 70D133A6BA7; Mon, 12 May 2008 14:15:03 -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-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080512211503.70D133A6BA7@core3.amsl.com> Date: Mon, 12 May 2008 14:15:03 -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-02.txt Pages : 18 Date : 2008-5-12 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-02.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-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-5-12140128.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 m4CLF3G4032302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 14:15: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 m4CLF3XJ032300; Mon, 12 May 2008 14:15: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 [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4CLF25L032271 for ; Mon, 12 May 2008 14:15:02 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 89EA13A6BA9; Mon, 12 May 2008 14:15:03 -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-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080512211503.89EA13A6BA9@core3.amsl.com> Date: Mon, 12 May 2008 14:15:03 -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-02.txt Pages : 40 Date : 2008-5-12 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-02.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-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-5-12140710.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 m4CKqEiL023301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 13:52: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 m4CKqEhl023299; Mon, 12 May 2008 13:52: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 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 m4CKqBUB023255; Mon, 12 May 2008 13:52:13 -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 m4CKqAP0002728; Mon, 12 May 2008 16:52:11 -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 m4CKqAJV002722; Mon, 12 May 2008 16:52:10 -0400 Received: from m5922fa48.tmodns.net ([172.31.11.241]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 May 2008 16:52:09 -0400 Cc: Message-Id: <93A6E28F-962E-4D08-B671-D66EB226AADC@mitre.org> From: Timothy J Miller To: Paul Hoffman In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-20-390051725; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: S/MIME v3.2 IDs key size text (resend, no signature) Date: Mon, 12 May 2008 15:51:22 -0500 References: <004c01c8b44b$328b0e60$02b5a8c0@tony> <58461908-4572-411C-AFD5-BE8BF8A5E5FD@mitre.org> X-Mailer: Apple Mail (2.919.2) X-OriginalArrivalTime: 12 May 2008 20:52:10.0369 (UTC) FILETIME=[0C2E4710:01C8B472] Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-20-390051725 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On May 12, 2008, at 3:19 PM, Paul Hoffman wrote: > Only somewhat similar. Tony's proposed changes has a "SHOULD inform" > and a "SHOULD provide a warning". The quoted test is "SHOULD provide > alternate processing" which may be displaying a message. That's a > big difference. Yet the very next paragraph says: """ A receiving agent SHOULD display a subject name or other certificate details when displaying an indication of successful or unsuccessful signature verification. """ Sounds the same to me. Here's the thing: You're advocating interpreting the spec as purely a protocol spec. If that's what you're after, then that's a bigger issue than trading barbs over key length recommendations. There are a number of clauses that require UI implementation that need to be struck out (or at least moved to the security considerations section). But here's my problem with that thinking: S/MIME isn't just a protocol, it's a ceremony. There's an fundamental UI aspect to ceremonies. This needs to be dealt with properly and *prominently* or we'll end up with implementations that don't just *allow* bad things to be done, but that *mislead users* into thinking things are true about messages that just aren't. Moving all UI-related issues or security related recommendations to a separate section lowers their visibility, and that's not a good thing IMHO. -- Tim --Apple-Mail-20-390051725 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 AUcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwNTEyMjA1MTIz WjAjBgkqhkiG9w0BCQQxFgQU5KG52Qmw3YJDsT1LUJDKcc3dPQswcgYJKwYBBAGCNxAEMWUwYzBd MRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUG A1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIGmjB0BgsqhkiG9w0BCRACCzFl oGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowDQYJKoZIhvcNAQEB BQAEgYCrSr7eoyH+LO2/OWxaAbHjRaC3E740c49RwIXTCPZzU8tE5wtL9xcw0xvdDJASQHKL0Bk/ /IRkj/u7EDSTXAUscRYO+F/TkaMZfOldCnZzMnwzUNPjy4Fv+1JCVTzAR6rnFRx312bkH1kuBj1F RPP4xRZi4bAhxzP/5nNFAVMzjAAAAAAAAA== --Apple-Mail-20-390051725-- 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 m4CKJGmS011414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 13:19:16 -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 m4CKJGfY011412; Mon, 12 May 2008 13:19:16 -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] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4CKJEF9011388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 13:19:14 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <58461908-4572-411C-AFD5-BE8BF8A5E5FD@mitre.org> References: <004c01c8b44b$328b0e60$02b5a8c0@tony> <58461908-4572-411C-AFD5-BE8BF8A5E5FD@mitre.org> Date: Mon, 12 May 2008 13:19:10 -0700 To: Timothy J Miller From: Paul Hoffman Subject: Re: S/MIME v3.2 IDs key size text (resend, no signature) 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:43 PM -0500 5/12/08, Timothy J Miller wrote: >On May 12, 2008, at 11:49 AM, Paul Hoffman wrote: >> >>>When feasible, sending and receiving agents SHOULD inform senders (prior >>>to transmission) and recipients of the relative cryptographic strength of >>>messages and SHOULD provide a warning if weak algorithms or key sizes are >>>used. >> >>I'm lost here. Using the protocol described in the document, how >>would I send such information? How would I send such a warning? > >Yet similar advice exists elsewhere in the cert handling spec: > >""" >A receiving agent SHOULD provide some explicit alternate processing >of the message if this comparison fails, which may be to display >a message that shows the recipient the addresses in the certificate >or other certificate details. >""" (ref: sec 3) Only somewhat similar. Tony's proposed changes has a "SHOULD inform" and a "SHOULD provide a warning". The quoted test is "SHOULD provide alternate processing" which may be displaying a message. That's a big difference. >Are you saying that this should come out as well, since your >objection to the RFC advising implementors to warn users re: key >strength clearly also applies to the RFC advising implementors re: >an email mismatch? Nope. I have nothing against advising implementers. Heck, I've written a lot of the text that does that. What I object to is a SHOULD-level "inform" or "provide a warning" when we have no protocol-standard way of doing so. 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 m4CK8Sab007401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 13:08:28 -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 m4CK8SK6007400; Mon, 12 May 2008 13:08:28 -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 smtp109.biz.mail.re2.yahoo.com (smtp109.biz.mail.re2.yahoo.com [206.190.53.8]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m4CK8QlH007376 for ; Mon, 12 May 2008 13:08:26 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 17488 invoked from network); 12 May 2008 20:08:25 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.241.98.201 with login) by smtp109.biz.mail.re2.yahoo.com with SMTP; 12 May 2008 20:08:25 -0000 X-YMail-OSG: cBcgFMYVM1n0fcMmdKMcBD_1KDZLNKuOaICyn_nKTd3qLSN_eC.5VG0AMeOGDeDk65QvRbbmbGWpr7filzEg21oBui3etuwgTMukTjvjkeS_2Ho4VaMygjgIGsf52La8DOU- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: References: <012201c8a62a$16f76b50$0301a8c0@Wylie> from "Turner, Sean P." at Apr "24," 2008 "12:41:47" pm <200804241739.TAA28425@TR-Sys.de> Subject: RE: draft-ietf-smime-rfc3278-update-02 Date: Mon, 12 May 2008 16:08:17 -0400 Organization: IECA, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcimMjbqqRqg/Uf9Sfu6Jz1WY9sGcAOOU8IA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: <200804241739.TAA28425@TR-Sys.de> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >-----Original Message----- >From: Alfred H=CEnes [mailto:ah@tr-sys.de]=20 >Sent: Thursday, April 24, 2008 1:39 PM >To: turners@ieca.com >Cc: DBrown@certicom.com; ietf-smime@imc.org >Subject: Re: draft-ietf-smime-rfc3278-update-02 >> All, >>=20 >> Does anybody think it would be clearer to resubmit this to be a bis=20 >> draft (i.e., obsolete 3278) instead of an update draft? >> Originally, the draft just updated the ECDSA 224-512 and SHA2=20 >> algorithms, but now it updates most of the sections in RFC3278. >> I think it might be clearer to just obsolete RFC3278. >>=20 >> spt > >When it comes to security, unnecessary complexity is evil. >And complexity sometimes starts with the specification(s). > >In this case, the current draft already is an excellent=20 >example of how documents updating earlier specifications=20 >should be written to avoid any ambiguity related to what in=20 >detail is updated in which manner. > >Nevertheless, I strongly support the idea to merge the still=20 >valid parts of RFC 3278 with this draft, to obtain a single=20 >concise replacement document. There are lots of examples=20 >where RFCs have been superseded by newer ones for much less=20 >substantial updates. I haven't heard an objection to this so I'm going to submit a new -00 ID that is going to obsolete 3278 as opposed to update it. The current ID = will die on the vine. >A unified new document would also allow to update all the Refs=20 >in 3278 (including RFC-to-be 5280), split these into Normative=20 >and Informative, and adapt the boilerplate matter to the new=20 >ISOC/IETF position on IPR stuff. > >But when this step is undertaken, the next question immediately >arises: Why not also going from Informational to Standards Track? Since there's IPR with ECC all the IETF IDs/RFCs that deal with ECC are Informational. 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 m4CIiV9o075924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 11:44: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 m4CIiVlC075923; Mon, 12 May 2008 11:44: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 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 m4CIiTHa075879; Mon, 12 May 2008 11:44:30 -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 m4CIiR8r011806; Mon, 12 May 2008 14:44:28 -0400 Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m4CIiQc0011753; Mon, 12 May 2008 14:44:26 -0400 Received: from m5922fa48.tmodns.net ([172.31.11.160]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 May 2008 14:44:25 -0400 Cc: "Tony Capel" , Message-Id: <58461908-4572-411C-AFD5-BE8BF8A5E5FD@mitre.org> From: Timothy J Miller To: Paul Hoffman In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-16-382386151; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: S/MIME v3.2 IDs key size text (resend, no signature) Date: Mon, 12 May 2008 13:43:37 -0500 References: <004c01c8b44b$328b0e60$02b5a8c0@tony> X-Mailer: Apple Mail (2.919.2) X-OriginalArrivalTime: 12 May 2008 18:44:26.0744 (UTC) FILETIME=[344DE780:01C8B460] Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-16-382386151 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On May 12, 2008, at 11:49 AM, Paul Hoffman wrote: > >> When feasible, sending and receiving agents SHOULD inform senders >> (prior >> to transmission) and recipients of the relative cryptographic >> strength of >> messages and SHOULD provide a warning if weak algorithms or key >> sizes are >> used. > > I'm lost here. Using the protocol described in the document, how > would I send such information? How would I send such a warning? Yet similar advice exists elsewhere in the cert handling spec: """ A receiving agent SHOULD provide some explicit alternate processing of the message if this comparison fails, which may be to display a message that shows the recipient the addresses in the certificate or other certificate details. """ (ref: sec 3) Are you saying that this should come out as well, since your objection to the RFC advising implementors to warn users re: key strength clearly also applies to the RFC advising implementors re: an email mismatch? -- Tim --Apple-Mail-16-382386151 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 AUcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwNTEyMTg0MzM3 WjAjBgkqhkiG9w0BCQQxFgQU3xPlGCn4zWG6rNM43KlvJiNFnz8wcgYJKwYBBAGCNxAEMWUwYzBd MRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUG A1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIGmjB0BgsqhkiG9w0BCRACCzFl oGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowDQYJKoZIhvcNAQEB BQAEgYABTBa2ao0ryMtm/DybGB4+4jtdiKcPM7H0K03bsboq4WayEgFKQZ+z0PCCS7ExORBHKP+x HUrtbhFkN4SJVtOlR8xwNSg0VBRFFzrAeZz6rBSYznn3ohJxw3ayh22pR2YD1r6uTN2dKOBfLHm3 kWCAqeBPb/EEVcTC30rXB6/mPAAAAAAAAA== --Apple-Mail-16-382386151-- 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 m4CGoPOd035204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 09:50: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 m4CGoPrQ035203; Mon, 12 May 2008 09:50:25 -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 m4CGoFGK035108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 09:50:16 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 12 May 2008 09:36:30 -0700 To: pgut001@cs.auckland.ac.nz (Peter Gutmann) From: Paul Hoffman Subject: Re: S/MIME v3.2 IDs key size text Cc: ietf-smime@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 3:32 AM +1200 5/13/08, Peter Gutmann wrote: >Paul Hoffman writes: > >>We are not the security nannies of the Internet. As long as we give a >>reasonable number of bits that all implementations should be able to sign and >>verify in order to make reasonably-strong signatures, we should step back and >>let organizations make their own rules. > >No, that's exactly what we shouldn't do, because then organisations will use >the fact that the standard doesn't set a sane limit on the key size to justify >using completely stupid key sizes (or as a generalisation completely insecure >"security" practices) [0]. You'll need to justify this one, Peter. Show me some examples where any previous version of S/MIME, none of which have "sane" lower limits, was used by any organization to justify a stupid key size. >I realise that it's not possible to explicitly >outlaw every kind of stupid behaviour that users will engage in, but since >there's a list of key sizes in the doc anyway it's a pretty trivial change to >add a sensible lower bound to it. It is a list of two elements: there is already a sensible lower bound. Please suggest specific text that would meet your criteria. 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 m4CGoMcY035183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 09:50: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 m4CGoMPL035181; Mon, 12 May 2008 09:50: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 [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 m4CGoFGM035108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 09:50:17 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <004c01c8b44b$328b0e60$02b5a8c0@tony> References: <004c01c8b44b$328b0e60$02b5a8c0@tony> Date: Mon, 12 May 2008 09:49:00 -0700 To: "Tony Capel" From: Paul Hoffman Subject: RE: S/MIME v3.2 IDs key size text (resend, no signature) Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:14 PM -0400 5/12/08, Tony Capel wrote: >Sean et al: > >How about: > > 0 < key size < 512 : MAY but refer to security considerations >section > 512 <= key size < 1024 : SHOULD- but refer to security considerations >section >1024 <= key size <= 2048 : MUST >2048 < key size : MAY but refer to security considerations >section Could you add verbs to your table? MAY what? SHOULD- what? >"A denial of service opportunity may exploitable by attackers who provide >an excessively large key, or a key selected to require excessive >cryptographic processing. One mitigation approach would require that the >corresponding public key certificate be validated to a trusted root [trust >anchor] prior to use, thus ensuring that only trusted public keys are >used. However, some implementations may choose to perform signature >verification (or data encryption) in parallel with certificate validation, >or 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." Regardless of small key size issue, I think text like this would be a good addition to the Security Considerations section of many documents. >Proposed Draft text: > >"Using weak cryptography in S/MIME offers little actual security over >sending plaintext. >Some cryptographers consider public keys of less than 1024* bits to be >weak, along with symmetric encryption algorithms of less than 64 bits and >certain older hash algorithms used for signing. And some don't consider 1024 bits weak. For example, there are lots of 1024-bit certificates in the trust anchor pile in your browser. To date, no one is known to have compromised even one of them, even though doing so would have higher value than compromising almost any individual's signing key. Cryptographers who look at the real world of costs and benefits have noticed this. >In any given application, an appropriate analysis of the threats and risks >SHOULD lead to the selection of appropriate algorithms and key sizes. That SHOULD is misplaced. Please re-read RFC 2119. Further, we all know that this sentence is more often false than true in the real world. What is the advantage of reproducing this fairy tale in the S/MIME spec? >When feasible, sending and receiving agents SHOULD inform senders (prior >to transmission) and recipients of the relative cryptographic strength of >messages and SHOULD provide a warning if weak algorithms or key sizes are >used. I'm lost here. Using the protocol described in the document, how would I send such information? How would I send such a warning? 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 m4CGED49021559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 09:14: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 m4CGED8i021558; Mon, 12 May 2008 09:14: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 mail-02.primus.ca (mail.tor.primus.ca [216.254.136.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4CGEBCd021533; Mon, 12 May 2008 09:14:12 -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 1JvafD-0005jd-0E; Mon, 12 May 2008 12:14:11 -0400 From: "Tony Capel" To: "'Timothy J Miller'" , "'Paul Hoffman'" Cc: "'Turner, Sean P.'" , Subject: RE: S/MIME v3.2 IDs key size text (resend, no signature) Date: Mon, 12 May 2008 12:14:03 -0400 Message-ID: <004c01c8b44b$328b0e60$02b5a8c0@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: thread-index: Aci0NleKTUV18uyISbCzl6pNQOuo+QAFGQ3Q Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sean et al: How about: 0 < key size < 512 : MAY but refer to security considerations section 512 <= key size < 1024 : SHOULD- but refer to security considerations section 1024 <= key size <= 2048 : MUST 2048 < key size : MAY but refer to security considerations section For larger keys, some text for the security considerations section might be added, e.g. something like: "A denial of service opportunity may exploitable by attackers who provide an excessively large key, or a key selected to require excessive cryptographic processing. One mitigation approach would require that the corresponding public key certificate be validated to a trusted root [trust anchor] prior to use, thus ensuring that only trusted public keys are used. However, some implementations may choose to perform signature verification (or data encryption) in parallel with certificate validation, or 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." For smaller keys, this is already addressed to some extent for encryption in the security considerations section, maybe this needs updating based on our experience with smime: Current text: 40-bit encryption is considered weak by most cryptographers. Using weak cryptography in S/MIME offers little actual security over sending plaintext. However, other features of S/MIME, such as the specification of tripleDES and the ability to announce stronger cryptographic capabilities to parties with whom you communicate, allow senders to create messages that use strong encryption. Using weak cryptography is never recommended unless the only alternative is no cryptography. When feasible, sending and receiving agents SHOULD inform senders and recipients of the relative cryptographic strength of messages. Proposed Draft text: "Using weak cryptography in S/MIME offers little actual security over sending plaintext. Some cryptographers consider public keys of less than 1024* bits to be weak, along with symmetric encryption algorithms of less than 64 bits and certain older hash algorithms used for signing. In any given application, an appropriate analysis of the threats and risks SHOULD lead to the selection of appropriate algorithms and key sizes. For public keys, algorithms and key sizes are normally defined by the public key issuer in the corresponding certificate, and thus not under the control of the end user. For symmetric encryption and hash algorithms, S/MIME supports the ability of parties to communicate their capabilities to each other, allowing the use of appropriately strong measures. When feasible, sending and receiving agents SHOULD inform senders (prior to transmission) and recipients of the relative cryptographic strength of messages and SHOULD provide a warning if weak algorithms or key sizes are used. Such warnings are especially important if the symmetric encryption or hash algorithm are significantly weaker than the corresponding public key, since this will result in a message with weaker security than that implied by the public key certificate. " Tony * of course this could be a smaller value. PS: sorry about earlier e-mail with opaque signing, I did a "Reply to" which copied the security properties from Timothy's e-mail (but not cleartext option!) - defaulting to signing which I did not intend!!! | -----Original Message----- | From: owner-ietf-smime@mail.imc.org | [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Timothy J Miller | Sent: May 12, 2008 9:31 AM | To: Paul Hoffman | Cc: Turner, Sean P.; ietf-smime@imc.org | Subject: Re: S/MIME v3.2 IDs key size text | | | | On May 9, 2008, at 4:40 PM, Paul Hoffman wrote: | > | > At 12:37 PM -0400 5/6/08, Turner, Sean P. wrote: | >> | >> 0 < key size < 511 : MUST NOT | >> 512 < key size < 1023 : SHOULD- | | > Beyond what Russ just pointed out, I find the first line to be in | > bad taste. Any IETF spec that says "you must not be able to | verify a | > signature even though it is valid" is pretty offensive. | | How about adding a "MUST warn the user that key is too damn short to | be considered safe, even though the signature is valid" | clause instead? | | -- Tim | | | -----Original Message----- | From: owner-ietf-smime@mail.imc.org | [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Timothy J Miller | Sent: May 12, 2008 9:31 AM | To: Paul Hoffman | Cc: Turner, Sean P.; ietf-smime@imc.org | Subject: Re: S/MIME v3.2 IDs key size text | | | | On May 9, 2008, at 4:40 PM, Paul Hoffman wrote: | > | > At 12:37 PM -0400 5/6/08, Turner, Sean P. wrote: | >> | >> 0 < key size < 511 : MUST NOT | >> 512 < key size < 1023 : SHOULD- | | > Beyond what Russ just pointed out, I find the first line to be in | > bad taste. Any IETF spec that says "you must not be able to | verify a | > signature even though it is valid" is pretty offensive. | | How about adding a "MUST warn the user that key is too damn short to | be considered safe, even though the signature is valid" | clause instead? | | -- Tim | | 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 m4CFxgDl016897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 08:59:42 -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 m4CFxgoo016896; Mon, 12 May 2008 08:59:42 -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 (mail.tor.primus.ca [216.254.136.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4CFxf59016866; Mon, 12 May 2008 08:59:41 -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 1JvaRA-00021p-1K; Mon, 12 May 2008 11:59:40 -0400 From: "Tony Capel" To: "'Turner, Sean P.'" Cc: , "'Paul Hoffman'" , "'Timothy J Miller'" Subject: RE: S/MIME v3.2 IDs key size text Date: Mon, 12 May 2008 11:59:32 -0400 Message-ID: <003501c8b449$2b88d860$02b5a8c0@tony> MIME-Version: 1.0 Content-Type: application/pkcs7-mime; smime-type=signed-data; name="smime.p7m" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7m" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6838 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: thread-index: Aci0NleKTUV18uyISbCzl6pNQOuo+QACQnEw Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEU0NvbnRl bnQtVHlwZTogdGV4dC9wbGFpbjsNCgljaGFyc2V0PSJ1cy1hc2NpaSINCkNvbnRlbnQtVHJhbnNm ZXItRW5jb2Rpbmc6IDdiaXQNCg0KBIIQolNlYW4gZXQgYWw6DQoNCkhvdyBhYm91dDoNCg0KICAg MCA8ICBrZXkgc2l6ZSA8IDUxMiAgICAgOiBNQVkgICAgIGJ1dCByZWZlciB0byBzZWN1cml0eSBj b25zaWRlcmF0aW9ucw0Kc2VjdGlvbg0KIDUxMiA8PSBrZXkgc2l6ZSA8IDEwMjQgICAgOiBTSE9V TEQtIGJ1dCByZWZlciB0byBzZWN1cml0eSBjb25zaWRlcmF0aW9ucw0Kc2VjdGlvbg0KMTAyNCA8 PSBrZXkgc2l6ZSA8PSAyMDQ4ICAgOiBNVVNUDQoyMDQ4IDwgIGtleSBzaXplICAgICAgICAgICA6 IE1BWSAgICAgYnV0IHJlZmVyIHRvIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zDQpzZWN0aW9uDQoN CkZvciBsYXJnZXIga2V5cywgc29tZSB0ZXh0IGZvciB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlv bnMgc2VjdGlvbiBtaWdodA0KYmUgYWRkZWQsIGUuZy4gc29tZXRoaW5nIGxpa2U6DQoNCiJBIGRl bmlhbCBvZiBzZXJ2aWNlIG9wcG9ydHVuaXR5IG1heSBleHBsb2l0YWJsZSBieSBhdHRhY2tlcnMg d2hvIHByb3ZpZGUNCmFuIGV4Y2Vzc2l2ZWx5IGxhcmdlIGtleSwgb3IgYSBrZXkgc2VsZWN0ZWQg dG8gcmVxdWlyZSBleGNlc3NpdmUNCmNyeXB0b2dyYXBoaWMgcHJvY2Vzc2luZy4gIE9uZSBtaXRp Z2F0aW9uIGFwcHJvYWNoIHdvdWxkIHJlcXVpcmUgdGhhdCB0aGUNCmNvcnJlc3BvbmRpbmcgcHVi bGljIGtleSBjZXJ0aWZpY2F0ZSBiZSB2YWxpZGF0ZWQgdG8gYSB0cnVzdGVkIHJvb3QgW3RydXN0 DQphbmNob3JdIHByaW9yIHRvIHVzZSwgdGh1cyBlbnN1cmluZyB0aGF0IG9ubHkgdHJ1c3RlZCBw dWJsaWMga2V5cyBhcmUNCnVzZWQuICBIb3dldmVyLCBzb21lIGltcGxlbWVudGF0aW9ucyBtYXkg Y2hvb3NlIHRvIHBlcmZvcm0gc2lnbmF0dXJlDQp2ZXJpZmljYXRpb24gKG9yIGRhdGEgZW5jcnlw dGlvbikgaW4gcGFyYWxsZWwgd2l0aCBjZXJ0aWZpY2F0ZSB2YWxpZGF0aW9uLA0Kb3IgZXZlbiBp ZiBjZXJ0aWZpY2F0ZSB2YWxpZGF0aW9uIGZhaWxzLiAgSW4gc3VjaCBjYXNlcywgbWVhc3VyZXMg c2hvdWxkDQpiZSBpbmNsdWRlZCB0byBsaW1pdCB0aGUgaW1wYWN0LCBmb3IgZXhhbXBsZSBieSBs aW1pdGluZyBjcnlwdG9ncmFwaGljDQpwcm9jZXNzaW5nIHRpbWUgb3IgcmVxdWlyaW5nIGNlcnRp ZmljYXRlIHZhbGlkYXRpb24gcHJpb3IgdG8gdGhlIHVzZSBvZg0KbGFyZ2Uga2V5cy4iDQoNCkZv ciBzbWFsbGVyIGtleXMsIHRoaXMgaXMgYWxyZWFkeSBhZGRyZXNzZWQgdG8gc29tZSBleHRlbnQg Zm9yIGVuY3J5cHRpb24NCmluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLCBt YXliZSB0aGlzIG5lZWRzIHVwZGF0aW5nIGJhc2VkIG9uDQpvdXIgZXhwZXJpZW5jZSB3aXRoIHNt aW1lOg0KDQpDdXJyZW50IHRleHQ6DQoNCiAgIDQwLWJpdCBlbmNyeXB0aW9uIGlzIGNvbnNpZGVy ZWQgd2VhayBieSBtb3N0IGNyeXB0b2dyYXBoZXJzLiBVc2luZw0KICAgd2VhayBjcnlwdG9ncmFw aHkgaW4gUy9NSU1FIG9mZmVycyBsaXR0bGUgYWN0dWFsIHNlY3VyaXR5IG92ZXINCiAgIHNlbmRp bmcgcGxhaW50ZXh0LiAgSG93ZXZlciwgb3RoZXIgZmVhdHVyZXMgb2YgUy9NSU1FLCBzdWNoIGFz IHRoZQ0KICAgc3BlY2lmaWNhdGlvbiBvZiB0cmlwbGVERVMgYW5kIHRoZSBhYmlsaXR5IHRvIGFu bm91bmNlIHN0cm9uZ2VyDQogICBjcnlwdG9ncmFwaGljIGNhcGFiaWxpdGllcyB0byBwYXJ0aWVz IHdpdGggd2hvbSB5b3UgY29tbXVuaWNhdGUsDQogICBhbGxvdyBzZW5kZXJzIHRvIGNyZWF0ZSBt ZXNzYWdlcyB0aGF0IHVzZSBzdHJvbmcgZW5jcnlwdGlvbi4gIFVzaW5nDQogICB3ZWFrIGNyeXB0 b2dyYXBoeSBpcyBuZXZlciByZWNvbW1lbmRlZCB1bmxlc3MgdGhlIG9ubHkgYWx0ZXJuYXRpdmUg aXMNCiAgIG5vIGNyeXB0b2dyYXBoeS4gIFdoZW4gZmVhc2libGUsIHNlbmRpbmcgYW5kIHJlY2Vp dmluZyBhZ2VudHMgU0hPVUxEDQogICBpbmZvcm0gc2VuZGVycyBhbmQgcmVjaXBpZW50cyBvZiB0 aGUgcmVsYXRpdmUgY3J5cHRvZ3JhcGhpYyBzdHJlbmd0aA0KICAgb2YgbWVzc2FnZXMuDQoNClBy b3Bvc2VkIERyYWZ0IHRleHQ6DQoNCiJVc2luZyB3ZWFrIGNyeXB0b2dyYXBoeSBpbiBTL01JTUUg b2ZmZXJzIGxpdHRsZSBhY3R1YWwgc2VjdXJpdHkgb3Zlcg0Kc2VuZGluZyBwbGFpbnRleHQuDQpT b21lIGNyeXB0b2dyYXBoZXJzIGNvbnNpZGVyIHB1YmxpYyBrZXlzIG9mIGxlc3MgdGhhbiAxMDI0 KiBiaXRzIHRvIGJlDQp3ZWFrLCBhbG9uZyB3aXRoIHN5bW1ldHJpYyBlbmNyeXB0aW9uIGFsZ29y aXRobXMgb2YgbGVzcyB0aGFuIDY0IGJpdHMgYW5kDQpjZXJ0YWluIG9sZGVyIGhhc2ggYWxnb3Jp dGhtcyB1c2VkIGZvciBzaWduaW5nLg0KSW4gYW55IGdpdmVuIGFwcGxpY2F0aW9uLCBhbiBhcHBy b3ByaWF0ZSBhbmFseXNpcyBvZiB0aGUgdGhyZWF0cyBhbmQgcmlza3MNClNIT1VMRCBsZWFkIHRv IHRoZSBzZWxlY3Rpb24gb2YgYXBwcm9wcmlhdGUgYWxnb3JpdGhtcyBhbmQga2V5IHNpemVzLg0K Rm9yIHB1YmxpYyBrZXlzLCBhbGdvcml0aG1zIGFuZCBrZXkgc2l6ZXMgYXJlIG5vcm1hbGx5IGRl ZmluZWQgYnkgdGhlDQpwdWJsaWMga2V5IGlzc3VlciBpbiB0aGUgY29ycmVzcG9uZGluZyBjZXJ0 aWZpY2F0ZSwgYW5kIHRodXMgbm90IHVuZGVyIHRoZQ0KY29udHJvbCBvZiB0aGUgZW5kIHVzZXIu DQpGb3Igc3ltbWV0cmljIGVuY3J5cHRpb24gYW5kIGhhc2ggYWxnb3JpdGhtcywgUy9NSU1FIHN1 cHBvcnRzIHRoZSBhYmlsaXR5DQpvZiBwYXJ0aWVzIHRvIGNvbW11bmljYXRlIHRoZWlyIGNhcGFi aWxpdGllcyB0byBlYWNoIG90aGVyLCBhbGxvd2luZyB0aGUNCnVzZSBvZiBhcHByb3ByaWF0ZWx5 IHN0cm9uZyBtZWFzdXJlcy4NCldoZW4gZmVhc2libGUsIHNlbmRpbmcgYW5kIHJlY2VpdmluZyBh Z2VudHMgU0hPVUxEIGluZm9ybSBzZW5kZXJzIChwcmlvcg0KdG8gdHJhbnNtaXNzaW9uKSBhbmQg cmVjaXBpZW50cyBvZiB0aGUgcmVsYXRpdmUgY3J5cHRvZ3JhcGhpYyBzdHJlbmd0aCBvZg0KbWVz c2FnZXMgYW5kIFNIT1VMRCBwcm92aWRlIGEgd2FybmluZyBpZiB3ZWFrIGFsZ29yaXRobXMgb3Ig a2V5IHNpemVzIGFyZQ0KdXNlZC4NClN1Y2ggd2FybmluZ3MgYXJlIGVzcGVjaWFsbHkgaW1wb3J0 YW50IGlmIHRoZSBzeW1tZXRyaWMgZW5jcnlwdGlvbiBvciBoYXNoDQphbGdvcml0aG0gYXJlIHNp Z25pZmljYW50bHkgd2Vha2VyIHRoYW4gdGhlIGNvcnJlc3BvbmRpbmcgcHVibGljIGtleSwNCnNp bmNlIHRoaXMgd2lsbCByZXN1bHQgaW4gYSBtZXNzYWdlIHdpdGggd2Vha2VyIHNlY3VyaXR5IHRo YW4gdGhhdCBpbXBsaWVkDQpieSB0aGUgcHVibGljIGtleSBjZXJ0aWZpY2F0ZS4gIg0KDQoNCg0K VG9ueQ0KDQoqIG9mIGNvdXJzZSB0aGlzIGNvdWxkIGJlIGEgc21hbGxlciB2YWx1ZS4NCg0KfCAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KfCBGcm9tOiBvd25lci1pZXRmLXNtaW1lQG1haWwu aW1jLm9yZw0KfCBbbWFpbHRvOm93bmVyLWlldGYtc21pbWVAbWFpbC5pbWMub3JnXSBPbiBCZWhh bGYgT2YgVGltb3RoeSBKIE1pbGxlcg0KfCBTZW50OiBNYXkgMTIsIDIwMDggOTozMSBBTQ0KfCBU bzogUGF1bCBIb2ZmbWFuDQp8IENjOiBUdXJuZXIsIFNlYW4gUC47IGlldGYtc21pbWVAaW1jLm9y Zw0KfCBTdWJqZWN0OiBSZTogUy9NSU1FIHYzLjIgSURzIGtleSBzaXplIHRleHQNCnwNCnwNCnwN CnwgT24gTWF5IDksIDIwMDgsIGF0IDQ6NDAgUE0sIFBhdWwgSG9mZm1hbiB3cm90ZToNCnwgPg0K fCA+IEF0IDEyOjM3IFBNIC0wNDAwIDUvNi8wOCwgVHVybmVyLCBTZWFuIFAuIHdyb3RlOg0KfCA+ Pg0KfCA+PiAgIDAgPCBrZXkgc2l6ZSA8IDUxMSAgOiBNVVNUIE5PVA0KfCA+PiA1MTIgPCBrZXkg c2l6ZSA8IDEwMjMgOiBTSE9VTEQtDQp8DQp8ID4gQmV5b25kIHdoYXQgUnVzcyBqdXN0IHBvaW50 ZWQgb3V0LCBJIGZpbmQgdGhlIGZpcnN0IGxpbmUgdG8gYmUgaW4NCnwgPiBiYWQgdGFzdGUuIEFu eSBJRVRGIHNwZWMgdGhhdCBzYXlzICJ5b3UgbXVzdCBub3QgYmUgYWJsZSB0bw0KfCB2ZXJpZnkg YQ0KfCA+IHNpZ25hdHVyZSBldmVuIHRob3VnaCBpdCBpcyB2YWxpZCIgaXMgcHJldHR5IG9mZmVu c2l2ZS4NCnwNCnwgSG93IGFib3V0IGFkZGluZyBhICJNVVNUIHdhcm4gdGhlIHVzZXIgdGhhdCBr ZXkgaXMgdG9vIGRhbW4gc2hvcnQgdG8NCnwgYmUgY29uc2lkZXJlZCBzYWZlLCBldmVuIHRob3Vn aCB0aGUgc2lnbmF0dXJlIGlzIHZhbGlkIg0KfCBjbGF1c2UgaW5zdGVhZD8NCnwNCnwgLS0gVGlt DQp8DQp8DQoEAAAAAAAAAKCCClIwggTMMIIENaADAgECAhAcrp1rmvTmLyKKo9p0YWweMA0GCSqG SIb3DQEBBQUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UE CxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNTEw MjgwMDAwMDBaFw0xNTEwMjcyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDJ36zn 6vj4AxTEAJLVwX42wjzvfHIVy8CrjD0clc5vHhAsPwDtlybmtsfmrUMdP6SHR0dMPlT4bPjH/LGe vTBwvJexAwXqlfGtQMVEeksFovJg/Nc6ZWLv/xB7ola7xU5wLdaiHzztsELoXo1XIaymmdkR6dIa B8B0R0IL/MU06v3muiTRHQgVN6LXc88BQS9jsjo/vqUabvTJSls9laYVuzUCGfnU77yPDnF2WbtL tj7W/FoW9NYOifJJ/mwM7RXp2Yh1nHnOYCfdua11zi9zlXpAOoV1SbC432i8q80TgoURUKPgPAuu wApTzdcwb4UyRhvkSRDCbOKvH3n/27S1AgMBAAGjggGEMIIBgDASBgNVHRMBAf8ECDAGAQH/AgEA MEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWk IzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps 1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2Ex LmNybDCBgQYDVR0jBHoweKFjpGEwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5ghEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQUFAAOBgQCxL9mW4ZKi7oFg5cgqIPvh ZyzWAJhTowIb6ZBL+BhEnw9G9/qg/tMdGKPSvxzs1hmfSk1D+Mq7vhOASQXdIXMzV8JCWr76AJOy 5gQxkU5dPPBzBTdj67+DWZj9Zt7phjKakik8Oq5U2qYSUbGPyMrTR3jm26Uehwbj0RTAwiH2ujCC BX4wggRmoAMCAQICEESSWjobm8B74KlIfva/2j8wDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0 d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y cGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjAeFw0wODA0MTcwMDAwMDBa Fw0wOTA0MjAyMzU5NTlaMIIBFTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90 IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBT ZXJ2aWNlMRowGAYDVQQDFBFBLkMuIChUb255KSBDYXBlbDEgMB4GCSqGSIb3DQEJARYRY2FwZWxA Y29tZ2F0ZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtfsxOpz6QFfItcBlg xYSH9UbbQaogvaigfZAV45h+fnjVJ+n2zUA6XHOx7XwRZt8EgFcA4aSthXF3evO8DVqKBZcwwBcN 7ylVioSRlDD/TUvXScF+Uh77iC9+9cCN5+mWtNcf1rrBu3pLpViYObKS65JwxinyF9t2AhOLbkVZ hs7b9aKQHq6qAMvQhskxzfdr404pJUKVJ7gGoZOOv1uA3KQdKszXvkG5plO3eNNTaG74JyXTVuLE w/5/RDfaEtD3ayNSBozXWFoGkkD6qCMYtVYhbZFe1JFHU9eJT5Ps5cNmQ3qT43iM/96lqs81f8or ERTHMSvOt0gEJx02eRqZAgMBAAGjgf4wgfswCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG +EUBBxcDMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0P BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAwBgpghkgBhvhFAQYHBCIWIDcx NThjMjkzOGUyZDFkMGRkMTljMTA0MzAyN2QzYjFlMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9J bmRDMURpZ2l0YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDANBgkqhkiG 9w0BAQUFAAOCAQEApfrZkVZZ2pIl60wajeIbTEMslpmB3iHiD7joNe73Ipw+CWfhKKK/kmaSxSRH aKuIOsS2YMM4NHUQkdDA+/BRpBpVHEvdoghwsMh1RLmElt6iQcbnMCNVxvC/36F5loFfSp4TRTVJ GX+EH6It+F4faK88hEQXNNytqLQMHdgX6XSZlnj3M2BhhMUHkxNl7GPNHEkhOQK1J/x7bTx5YgoM pks8eKeO+tuM3GUYeGvy8SsOuWf+1hDaMotfIASiz1Y0z6CL/NImCFhOmMIO9R8z4HitRU5/MFsO lyxcGtxUbp+S9tDJ0bVCNhqvViIgnxCWJ8s4iguwImF4qviYNE9TCzGCBPQwggTwAgEBMIHyMIHd MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNV BAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEESSWjob m8B74KlIfva/2j8wCQYFKw4DAhoFAKCCAtYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDgwNTEyMTU1OTMyWjAjBgkqhkiG9w0BCQQxFgQUeaKpL9XJxQtPiF4g+1Rq OvNjazcwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAHBgUrDgMCGjAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwCgYIKoZIhvcNAgUwggED BgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNj cmliZXIgQ0EgLSBHMgIQRJJaOhubwHvgqUh+9r/aPzCCAQUGCyqGSIb3DQEJEAILMYH1oIHyMIHd MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNV BAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEESSWjob m8B74KlIfva/2j8wDQYJKoZIhvcNAQEBBQAEggEATBLKZ09eiUNYLCiSl1lzwobsz5JHVQhQY2zt Z9ekb3BaCbrWMCuzE098v1wtXPS4hrsLdCsTF46hy8wuu0uMsnT6Ev5XvDrEqqDXKM8ED3mEHbp9 X7tmqLFzecRdg1DD8kQMLll6iFvQxLCIAUQIMTmALC+xkxP2djHU7NCd+YdPYMAcuZa0SY3/V/lW +lNhW16jroZUxIWneX4oOKp2mqMBdKxJBqzmTJDZyj5vEkEkYPj8fxDRoMU+WooNWGBMdeVxqO2z TEbIbURsAju9lwUU5N8ezJTig5ygHcOcl9ZVVIpOncjI9U/rZlSoAeJkLudauwdHFHyEPSL8qYTy HgAAAAAAAA== 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 m4CFWval008849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 08:32:57 -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 m4CFWvYh008848; Mon, 12 May 2008 08:32:57 -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 mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4CFWtAK008808; Mon, 12 May 2008 08:32:56 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 48F0818609; Tue, 13 May 2008 03:32:51 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-x-kaXEnLtz; Tue, 13 May 2008 03:32:51 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2B176185F4; Tue, 13 May 2008 03:32:51 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 2C4B719EC0BA; Tue, 13 May 2008 03:32:46 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1Jva18-0002rS-0p; Tue, 13 May 2008 03:32:46 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: phoffman@imc.org, tmiller@mitre.org Subject: Re: S/MIME v3.2 IDs key size text Cc: ietf-smime@imc.org, turners@ieca.com In-Reply-To: Message-Id: Date: Tue, 13 May 2008 03:32:46 +1200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul Hoffman writes: >We are not the security nannies of the Internet. As long as we give a >reasonable number of bits that all implementations should be able to sign and >verify in order to make reasonably-strong signatures, we should step back and >let organizations make their own rules. No, that's exactly what we shouldn't do, because then organisations will use the fact that the standard doesn't set a sane limit on the key size to justify using completely stupid key sizes (or as a generalisation completely insecure "security" practices) [0]. I realise that it's not possible to explicitly outlaw every kind of stupid behaviour that users will engage in, but since there's a list of key sizes in the doc anyway it's a pretty trivial change to add a sensible lower bound to it. Peter. [0] The best one I've ever heard in this area was a government department that said that while a NIST standard required the use of security technology X, it didn't say it had to be *effectively* applied, merely applied (imagine the computer equivalent of "doors must be fitted with Medeco locks", but since the standard never said you have to actually lock the doors, merely that they had to be there, it was fine to leave all the doors unlocked). That's an extreme case, but it's merely the tip of the iceberg of lesser stupidity that organisations will engage in because a standard doesn't say they can't. 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 m4CFAhxI001596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 08:10:43 -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 m4CFAhK4001591; Mon, 12 May 2008 08:10:43 -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 m4CFAGip001402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 08:10:17 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <023701c8aef2$ad31a650$0201a8c0@Wylie> <004301c8aef7$bcafeba0$02b5a8c0@tony> <025e01c8af97$73f5a4e0$0201a8c0@Wylie> Date: Mon, 12 May 2008 08:10:10 -0700 To: Timothy J Miller From: Paul Hoffman Subject: Re: S/MIME v3.2 IDs key size text Cc: "Turner, Sean P." , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 8:31 AM -0500 5/12/08, Timothy J Miller wrote: >On May 9, 2008, at 4:40 PM, Paul Hoffman wrote: >> >>At 12:37 PM -0400 5/6/08, Turner, Sean P. wrote: >>> >>> 0 < key size < 511 : MUST NOT >>>512 < key size < 1023 : SHOULD- > >>Beyond what Russ just pointed out, I find the first line to be in >>bad taste. Any IETF spec that says "you must not be able to verify >>a signature even though it is valid" is pretty offensive. > >How about adding a "MUST warn the user that key is too damn short to >be considered safe, even though the signature is valid" clause >instead? I seriously doubt we could get consensus on the number of bits for that to kick in. Also, this would prevent an automated signature validation system with no UI from being able to be conformant. We are not the security nannies of the Internet. As long as we give a reasonable number of bits that all implementations should be able to sign and verify in order to make reasonably-strong signatures, we should step back and let organizations make their own rules. 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 m4CEHfUg080838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 07:17:41 -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 m4CEHf47080837; Mon, 12 May 2008 07:17:41 -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 mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4CEHdM6080784 for ; Mon, 12 May 2008 07:17:40 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 3022E185D9; Tue, 13 May 2008 02:17:35 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1t8m97zYr5x; Tue, 13 May 2008 02:17:35 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C477718617; Tue, 13 May 2008 02:17:33 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id D0DAD19EC0BA; Tue, 13 May 2008 02:17:29 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JvYqH-0007Vu-Mu; Tue, 13 May 2008 02:17:29 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: dbrown@certicom.com, ietf-smime@imc.org, ietf@augustcellars.com, pgut001@cs.auckland.ac.nz, trevorf@EXCHANGE.MICROSOFT.com Subject: RE: weak authentication issue with rfc5083 In-Reply-To: Message-Id: Date: Tue, 13 May 2008 02:17:29 +1200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Daniel Brown writes: >This is a serious problem, imo. If Bob receives an AuthenticatedData from >Alice but it is not really from Alice, then there really is no >authentication, despite the promise that AuthenticatedData provides >authentication. What security service is AuthenticatedData providing in this >case? Maybe it would have been better to call it IntegrityProtectedData :-). That's actually the only thing I've ever used it for, my assumption was that you sign email and you MAC stored data. Peter. 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 m4CE3G8a075098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 07:03:16 -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 m4CE3G5M075096; Mon, 12 May 2008 07:03:16 -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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m4CE3EuC075056 for ; Mon, 12 May 2008 07:03:14 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 7764 invoked from network); 12 May 2008 13:53:41 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;12 May 2008 13:53:41 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 12 May 2008 13:53:41 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: S/MIME v3.2 IDs key size text Date: Mon, 12 May 2008 10:03:10 -0400 Message-ID: in-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: S/MIME v3.2 IDs key size text Thread-Index: Aci0NwFQ77XqvYMvQnyonoenqEXKIwAAEz4g References: <023701c8aef2$ad31a650$0201a8c0@Wylie> <004301c8aef7$bcafeba0$02b5a8c0@tony> <025e01c8af97$73f5a4e0$0201a8c0@Wylie> From: "Carl Wallace" To: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > How about adding a "MUST warn the user that key is too damn short to be considered safe, even though the=20 > signature is valid" clause instead? >=20 > -- Tim This isn't sufficient for verification of archived email. A weak signature may be covered by a timestamp that enables its verification. This problem should be addressed using something like DSSC. =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 m4CDW8MC063216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 06:32: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 m4CDW8fk063215; Mon, 12 May 2008 06:32: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 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 m4CDW64W063201; Mon, 12 May 2008 06:32:07 -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 m4CDW5Nm004736; Mon, 12 May 2008 09:32:06 -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 m4CDW5Ai004728; Mon, 12 May 2008 09:32:05 -0400 Received: from m5922fa48.tmodns.net ([172.31.11.160]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 May 2008 09:32:02 -0400 Cc: "Turner, Sean P." , Message-Id: From: Timothy J Miller To: Paul Hoffman In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-5-363644505; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: S/MIME v3.2 IDs key size text Date: Mon, 12 May 2008 08:31:18 -0500 References: <023701c8aef2$ad31a650$0201a8c0@Wylie> <004301c8aef7$bcafeba0$02b5a8c0@tony> <025e01c8af97$73f5a4e0$0201a8c0@Wylie> X-Mailer: Apple Mail (2.919.2) X-OriginalArrivalTime: 12 May 2008 13:32:04.0048 (UTC) FILETIME=[90C97500:01C8B434] Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-5-363644505 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On May 9, 2008, at 4:40 PM, Paul Hoffman wrote: > > At 12:37 PM -0400 5/6/08, Turner, Sean P. wrote: >> >> 0 < key size < 511 : MUST NOT >> 512 < key size < 1023 : SHOULD- > Beyond what Russ just pointed out, I find the first line to be in > bad taste. Any IETF spec that says "you must not be able to verify a > signature even though it is valid" is pretty offensive. How about adding a "MUST warn the user that key is too damn short to be considered safe, even though the signature is valid" clause instead? -- Tim --Apple-Mail-5-363644505 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 AUcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwNTEyMTMzMTE4 WjAjBgkqhkiG9w0BCQQxFgQUxfk3lP26BF3SYLr1LRwVGQO/fiEwcgYJKwYBBAGCNxAEMWUwYzBd MRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUG A1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIGmjB0BgsqhkiG9w0BCRACCzFl oGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowDQYJKoZIhvcNAQEB BQAEgYBHUGdy3028S+XL94tRF7Tyw3kPdLmx1v8WVGCJl4kkgZ1E5cno8epj/UDK+jvLpdRXRw52 V5yJ1WRzaiVDWMv1Ysyj0ZhvbDnVQ0CFLt5MbrrHT+PC0or1TvvNq4gV3ZnLyQH2cZY0MMnSdgXh HTIPlCTRnSMDv0suVPh6sT0/ewAAAAAAAA== --Apple-Mail-5-363644505-- 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 m4AMNYpR025026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 May 2008 15:23:34 -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 m4AMNY8k025023; Sat, 10 May 2008 15:23:34 -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 m4AMN9so024877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 May 2008 15:23:11 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sat, 10 May 2008 15:23:07 -0700 To: pgut001@cs.auckland.ac.nz (Peter Gutmann), ietf-smime@imc.org, turners@ieca.com From: Paul Hoffman Subject: RE: S/MIME v3.2 IDs key size text Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 7:45 PM +1200 5/10/08, Peter Gutmann wrote: >Paul Hoffman writes: >>At 12:37 PM -0400 5/6/08, Turner, Sean P. wrote: >>> 0 < key size < 511 : MUST NOT >>> 512 < key size < 1023 : SHOULD- >>>1024 < key size < 2048 : MUST >>>2049 < key size < 4096 : MAY >> >>Beyond what Russ just pointed out, I find the first line to be in bad taste. >>Any IETF spec that says "you must not be able to verify a signature even >>though it is valid" is pretty offensive. > >So an implementation is supposed to do what, tell the user that they can be >absolutely totally assured that the signature is valid, all 12 bits of it? Yes. Why not? If you don't want to fully comply with the standard for any of a variety of reasons, by all means don't. 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 m4A8Hldp045019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 May 2008 01:17: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 m4A8HlJm045018; Sat, 10 May 2008 01:17: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 mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4A8HfH6044961; Sat, 10 May 2008 01:17:47 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id B22C618403; Sat, 10 May 2008 19:45:08 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUoLM2QmDnua; Sat, 10 May 2008 19:45:08 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 946AF183FF; Sat, 10 May 2008 19:45:01 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 4F6B119EC0BA; Sat, 10 May 2008 19:45:00 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JujlM-0003UN-5H; Sat, 10 May 2008 19:45:00 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org, phoffman@imc.org, turners@ieca.com Subject: RE: S/MIME v3.2 IDs key size text In-Reply-To: Message-Id: Date: Sat, 10 May 2008 19:45:00 +1200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul Hoffman writes: >At 12:37 PM -0400 5/6/08, Turner, Sean P. wrote: >> 0 < key size < 511 : MUST NOT >> 512 < key size < 1023 : SHOULD- >>1024 < key size < 2048 : MUST >>2049 < key size < 4096 : MAY > >Beyond what Russ just pointed out, I find the first line to be in bad taste. >Any IETF spec that says "you must not be able to verify a signature even >though it is valid" is pretty offensive. So an implementation is supposed to do what, tell the user that they can be absolutely totally assured that the signature is valid, all 12 bits of it? I guess it'll save implementation time because you can just report "signature might be valid" without even having to verify it. Peter. 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 m4A1EJZX076560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 May 2008 18:14:19 -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 m4A1EJRn076559; Fri, 9 May 2008 18:14:19 -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 m4A1ECms076505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 May 2008 18:14:14 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20080510001238.GA13646@dell-desktop.example.com> References: <023701c8aef2$ad31a650$0201a8c0@Wylie> <004301c8aef7$bcafeba0$02b5a8c0@tony> <025e01c8af97$73f5a4e0$0201a8c0@Wylie> <20080510001238.GA13646@dell-desktop.example.com> Date: Fri, 9 May 2008 18:14:10 -0700 To: Blake Ramsdell From: Paul Hoffman Subject: Re: S/MIME v3.2 IDs key size text Cc: "Turner, Sean P." , ietf-smime@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 5:12 PM -0700 5/9/08, Blake Ramsdell wrote: >On Fri, May 09, 2008 at 02:40:17PM -0700, Paul Hoffman wrote: >> Beyond what Russ just pointed out, I find the first line to be in bad >> taste. Any IETF spec that says "you must not be able to verify a signature >> even though it is valid" is pretty offensive. >> >> Can we return to talking about interoperability? > >I think you and I are on the same page, and there's two things: > >1. Interoperability. The key sizes to guarantee two implementations will talk > to each other. > >2. Security considerations. The key sizes that are a no-no due to insufficient > or overly-sufficient size. > >Have we given up on the separation of these? For interoperability, the receiver MUST be able to verify all sizes that the signer MUST be able to sign. For security, the signer MUST be able to sign using keys of at least a certain size. A receiver should expect that some of the signatures it wants to verify will be bigger than the one size in the spec because a receiver cannot accurately predict the security decisions of all the senders with which it interacts. I propose that that size is 1024 bits: that's plenty of strength for most typical non-paranoid applications for at least five years. If it turns out to be too short due to an unexpected large reduction in strength of RSA, we can revise then. Quite frankly, in that case, we might be recommending ECDSA anyhow. 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 m4A0ClFD049166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 May 2008 17:12: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 m4A0Cl1K049165; Fri, 9 May 2008 17:12: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 ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4A0Cjdr049144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 May 2008 17:12:46 -0700 (MST) (envelope-from blake@sendmail.com) Received: from fife.sendmail.com (fife.sendmail.com [209.246.26.50]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id m4A0Fd2C024470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 May 2008 17:15:40 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1210378540; bh=zWcwQk26qycMHwi7DfOWsWP2PTVm8sb+GhPc u2b6m+k=; h=Received:X-DKIM:DKIM-Signature:Date:From:To:Cc:Subject: Message-ID:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent:X-MM-Ex-RefId; b=N06dvm Iftu5CdrR2aazsKH9glp1w+1zFfOrgaozB8rIYkv/q7DR9nA9kWbkmD7LSSMEcFEC9n CT5tJIVMCi/dNxupa1qiuuE/4XXGj+jTvtzPedCqSZV2SnqErDQjgLB0CeNpND/lQPg VtP3w4Fq6c3SIfeqTPgJL48w+WF4kDI= Received: from dell-desktop.example.com (cpe-071-077-208-015.ec.res.rr.com [71.77.208.15]) (authenticated bits=0) by fife.sendmail.com (Switch-3.3.1/Switch-3.3.2mp) with ESMTP id m4A0CbZs017710 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 9 May 2008 17:12:42 -0700 X-DKIM: Sendmail DKIM Filter v2.2.3 fife.sendmail.com m4A0CbZs017710 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=fife.dkim; t=1210378363; bh=zWcwQk26qycMHwi7DfOWsWP2PTVm8sb+GhPcu 2b6m+k=; h=Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To: User-Agent:X-MM-Ex-RefId; b=sP/9dowMONzfAAmVPymL4enNbH/PvxAQz+cfPH EuzoxQjx4I0e6WjxNZZ8nrOtgGCVVhphJWSBppEblZUlAVhb8fpRRrcutYJ7UsnrtMt NU3tyhlFmJ5tV92kVIbohWWP11e+qDWj9Wg0cTv06F+PKH2X4SbOrq4pZ1PakfcBIA= Date: Fri, 9 May 2008 17:12:39 -0700 From: Blake Ramsdell To: Paul Hoffman Cc: "Turner, Sean P." , ietf-smime@imc.org Subject: Re: S/MIME v3.2 IDs key size text Message-ID: <20080510001238.GA13646@dell-desktop.example.com> References: <023701c8aef2$ad31a650$0201a8c0@Wylie> <004301c8aef7$bcafeba0$02b5a8c0@tony> <025e01c8af97$73f5a4e0$0201a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-MM-Ex-RefId: 149371::080509171243-0FBC0B90-13FD2C6A/0-0/0-1 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, May 09, 2008 at 02:40:17PM -0700, Paul Hoffman wrote: > Beyond what Russ just pointed out, I find the first line to be in bad > taste. Any IETF spec that says "you must not be able to verify a signature > even though it is valid" is pretty offensive. > > Can we return to talking about interoperability? I think you and I are on the same page, and there's two things: 1. Interoperability. The key sizes to guarantee two implementations will talk to each other. 2. Security considerations. The key sizes that are a no-no due to insufficient or overly-sufficient size. Have we given up on the separation of these? Blake 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 m49LeNot084146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 May 2008 14:40: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 m49LeN63084144; Fri, 9 May 2008 14:40: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 [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 m49LeKQm084116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 May 2008 14:40:21 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <025e01c8af97$73f5a4e0$0201a8c0@Wylie> References: <023701c8aef2$ad31a650$0201a8c0@Wylie> <004301c8aef7$bcafeba0$02b5a8c0@tony> <025e01c8af97$73f5a4e0$0201a8c0@Wylie> Date: Fri, 9 May 2008 14:40:17 -0700 To: "Turner, Sean P." , From: Paul Hoffman Subject: RE: S/MIME v3.2 IDs key size text Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:37 PM -0400 5/6/08, Turner, Sean P. wrote: >Just a thought ... since we've now got a way to indicate + and - with >requirements should we apply it the key sizes in 3850bis? That way people >will have a hint that in the next update the shorter keys will likely become >not so welcome and large keys more so? > > 0 < key size < 511 : MUST NOT > 512 < key size < 1023 : SHOULD- >1024 < key size < 2048 : MUST >2049 < key size < 4096 : MAY Beyond what Russ just pointed out, I find the first line to be in bad taste. Any IETF spec that says "you must not be able to verify a signature even though it is valid" is pretty offensive. Can we return to talking about interoperability? 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 m49KhES1068268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 May 2008 13:43: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 m49KhEBk068265; Fri, 9 May 2008 13:43: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 woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m49KhBYk068243 for ; Fri, 9 May 2008 13:43:12 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200805092043.m49KhBYk068243@balder-227.proper.com> Received: (qmail 9843 invoked by uid 0); 9 May 2008 20:43:05 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.129.167) by woodstock.binhost.com with SMTP; 9 May 2008 20:43:05 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 09 May 2008 14:11:21 -0400 To: "Turner, Sean P." , "'Tony Capel'" , "'Paul Hoffman'" , From: Russ Housley Subject: RE: S/MIME v3.2 IDs key size text In-Reply-To: <025e01c8af97$73f5a4e0$0201a8c0@Wylie> References: <023701c8aef2$ad31a650$0201a8c0@Wylie> <004301c8aef7$bcafeba0$02b5a8c0@tony> <025e01c8af97$73f5a4e0$0201a8c0@Wylie> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Are you saying that I MAY NOT support keys bigger than 4096? At 12:37 PM 5/6/2008, Turner, Sean P. wrote: > 0 < key size < 511 : MUST NOT > 512 < key size < 1023 : SHOULD- >1024 < key size < 2048 : MUST >2049 < key size < 4096 : MAY 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 m49JrUK5058907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 May 2008 12:53:30 -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 m49JrUce058906; Fri, 9 May 2008 12:53:30 -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.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.1.17]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m49JrSN8058899 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Fri, 9 May 2008 12:53:29 -0700 (MST) (envelope-from trevorf@exchange.microsoft.com) Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) by DF-GWY-05.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 9 May 2008 12:54:17 -0700 Received: from df-mlt-02.exchange.corp.microsoft.com (157.54.94.20) by df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 9 May 2008 12:54:16 -0700 Received: from DF-MBX-61.exchange.corp.microsoft.com ([157.54.109.22]) by DF-MLT-02.exchange.corp.microsoft.com ([157.54.94.20]) with mapi; Fri, 9 May 2008 12:53:52 -0700 From: Trevor Freeman To: pgut001 , "ietf-smime@imc.org" , "ietf@augustcellars.com" Date: Fri, 9 May 2008 19:53:02 +0000 Subject: RE: weak authentication issue with rfc5083 Thread-Topic: weak authentication issue with rfc5083 Thread-Index: Aciu6YBkwNV9yBxhQNWEO1d1mLywFgAab23AAKFFZGEADQtFEA== Message-ID: References: <14c501c8afaf$899e2700$9cda7500$@com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Peter, The push back to why doesn't everyone just use signatures is when I have an= existing security mechanism like Kerberos which builds secure pair wise ke= ys. Kerberos shared secrets can establish mutual authentication providing b= oth parties demonstrate knowledge of the shared secret. I don't think the s= olution is that complex. If I encrypt the MAC with the pair wise secret I a= chieve mutual authentication. We use the same mechanism to learn the CEK, w= e just need to do the same again to prove I know both the KEK and the MAC. Trevor -----Original Message----- From: pgut001 [mailto:pgut001@cs.auckland.ac.nz] Sent: Friday, May 09, 2008 6:26 AM To: ietf-smime@imc.org; ietf@augustcellars.com; pgut001@cs.aucKland.ac.nz; = Trevor Freeman Subject: RE: weak authentication issue with rfc5083 "Jim Schaad" writes: >I believe you have misunderstood the issue that Trevor raised. > >His problem is: > >1. I send you and him a single Authenticated Message. > >2. He takes the common CEK in the original message, uses it to create a MA= C >on an new message and then sends it on to you. > >As is always true with Authenticated messages, there is no proof of origin= . >He worries that you might be confused and believe the second messages was >from me rather than from him. Since they both use the same CEK that is no= t a >factor that could be used to distinguish them. Ah, OK, thanks. How serious a threat is this in practice though? Wouldn't people just use asymmetric auth if they're worried about proof of origin? = I realise it's kind of an interesting problem to solve, but does it need solv= ing beyond a security considerations note "If you're seriously worried about pr= oof of origin use a signature"? Peter. 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 m49EOVHB034135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 May 2008 07:24: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 m49EOVBw034134; Fri, 9 May 2008 07:24: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 cx295.800onemail.com (cx295.800onemail.com [209.171.54.152]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m49EOT03034102 for ; Fri, 9 May 2008 07:24:30 -0700 (MST) (envelope-from dbrown@certicom.com) Received: from ex13-n02.exchserver.com ([192.168.162.157]) by cx295.800onemail.com (8.13.1/8.13.1) with ESMTP id m49ELmJx026372; Fri, 9 May 2008 10:21:54 -0400 Received: from EX40.exchserver.com ([192.168.162.205]) by ex13-n02.exchserver.com ([192.168.162.161]) with mapi; Fri, 9 May 2008 10:18:49 -0400 From: Daniel Brown To: Peter Gutmann , "ietf-smime@imc.org" , "ietf@augustcellars.com" , "trevorf@EXCHANGE.MICROSOFT.com" Date: Fri, 9 May 2008 10:21:43 -0400 Subject: RE: weak authentication issue with rfc5083 Thread-Topic: weak authentication issue with rfc5083 Thread-Index: Acix2wfjBUv/oBsBQqurc4yjn91w8QAAeqSw Message-ID: References: <14c501c8afaf$899e2700$9cda7500$@com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CRXEFW-Info: Please contact Ceryx for more information X-CRXEFW-Virus: Clean X-CRXEFW-From: dbrown@certicom.com Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter, Jim, This is a serious problem, imo. If Bob receives an AuthenticatedData from = Alice but it is not really from Alice, then there really is no authenticati= on, despite the promise that AuthenticatedData provides authentication. Wh= at security service is AuthenticatedData providing in this case? If the Ch= arles is the attacker, then cannot Charles strip off his RecipientInfo from= the AuthenticatedData, in which case, Bob has no way of knowing that Alice= originallly sent the AuthenticatedData to two parties? A difference between SignedData and AuthenticatedData is that with the latt= er Bob cannot prove (cryptographically) to others that Alice authenticated = anything. That's the motivation to use AuthenticatedData instead of Signed= Data. *** Maybe AuthEnvData is a little different from AuthData, though. For example= , if the key management mechanism is key transport, so Alice provides no ce= rtificate, then effectively Alice is anonymous. In that case, the MAC only= protects integrity of the message from modification in transit, it does no= t provide authentication. (Cf. TLS with unauthenticated clients, where rec= ords are MAC for a similar purpose.) If AuthEnvData is used for that lesse= r purpose, then the substitutuion attack by Charles is not as significant, = because Alice is essentially anonymous. >From reading 5083, I interpret its intent only to be add integrity to EnvDa= ta, since CBC mode does not provide full integrity. However, for some choi= ces of key management, it has the further capability of authenticating the = sender (i.e. if the key management authenticates the sender, which in does = in all cases except key transport). This is a useful capability and should= be noted. Regardless, it should be emphasized that, at least in the case = of key transport, that no actual authentication is provided (just integrity= ). Otherwise, evidently there is a risk of misinterpretation. Best regards, Dan -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Peter Gutmann Sent: Friday, May 09, 2008 9:26 AM To: ietf-smime@imc.org; ietf@augustcellars.com; pgut001@cs.auckland.ac.nz; = trevorf@EXCHANGE.MICROSOFT.com Subject: RE: weak authentication issue with rfc5083 "Jim Schaad" writes: >I believe you have misunderstood the issue that Trevor raised. > >His problem is: > >1. I send you and him a single Authenticated Message. > >2. He takes the common CEK in the original message, uses it to create a MA= C >on an new message and then sends it on to you. > >As is always true with Authenticated messages, there is no proof of origin= . >He worries that you might be confused and believe the second messages was >from me rather than from him. Since they both use the same CEK that is no= t a >factor that could be used to distinguish them. Ah, OK, thanks. How serious a threat is this in practice though? Wouldn't people just use asymmetric auth if they're worried about proof of origin? = I realise it's kind of an interesting problem to solve, but does it need solv= ing beyond a security considerations note "If you're seriously worried about pr= oof of origin use a signature"? Peter. 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 m49DPpLq009453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 May 2008 06:25: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 m49DPpUE009452; Fri, 9 May 2008 06:25: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 mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m49DPnka009423 for ; Fri, 9 May 2008 06:25:50 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 0963348059D; Sat, 10 May 2008 01:25:49 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzRZ-RTRMT1p; Sat, 10 May 2008 01:25:48 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 9AFBD480594; Sat, 10 May 2008 01:25:48 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id D745E19EC0BA; Sat, 10 May 2008 01:25:46 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JuSba-0006rY-Ow; Sat, 10 May 2008 01:25:46 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org, ietf@augustcellars.com, pgut001@cs.auckland.ac.nz, trevorf@EXCHANGE.MICROSOFT.com Subject: RE: weak authentication issue with rfc5083 In-Reply-To: <14c501c8afaf$899e2700$9cda7500$@com> Message-Id: Date: Sat, 10 May 2008 01:25:46 +1200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Jim Schaad" writes: >I believe you have misunderstood the issue that Trevor raised. > >His problem is: > >1. I send you and him a single Authenticated Message. > >2. He takes the common CEK in the original message, uses it to create a MAC >on an new message and then sends it on to you. > >As is always true with Authenticated messages, there is no proof of origin. >He worries that you might be confused and believe the second messages was >from me rather than from him. Since they both use the same CEK that is not a >factor that could be used to distinguish them. Ah, OK, thanks. How serious a threat is this in practice though? Wouldn't people just use asymmetric auth if they're worried about proof of origin? I realise it's kind of an interesting problem to solve, but does it need solving beyond a security considerations note "If you're seriously worried about proof of origin use a signature"? Peter. 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 m47E0gWr051578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 May 2008 07:00:42 -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 m47E0g4V051576; Wed, 7 May 2008 07:00:42 -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.nist.gov (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m47E0ecV051560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 7 May 2008 07:00:41 -0700 (MST) (envelope-from tim.polk@nist.gov) Received: from [192.168.15.166] (bethany.ncsl.nist.gov [129.6.52.15]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m47E0WpT018739; Wed, 7 May 2008 10:00:32 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) References: <7.0.1.0.2.20080506160054.0251ad30@nist.gov> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <89EDB6AD-61F0-4D14-9AF7-F4A79AE2481F@nist.gov> Content-Transfer-Encoding: 7bit From: Tim Polk Subject: Fwd: NIST Identity-Based Encryption Workshop- Registration Deadline Approaching Date: Wed, 7 May 2008 10:00:36 -0400 To: saag@mit.edu, S-MIME / IETF X-Mailer: Apple Mail (2.752.2) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, My apologies for a brief advertisement... I am forwarding this workshop announcement since IBE documents are currently progressing through one of the security area working groups, and because I am always anxious to see the needs of the Internet community considered by NIST in our standardization activities. Attendance is one way to ensure your voice is heard. If you have a strong opinion about IBE and are unable to attend, please let me know so I can pass it along! Note that the early registration fee is only available through the end of the week. Thanks, Tim Polk Begin forwarded message: > From: Andrew Regenscheid > Date: May 6, 2008 4:08:35 PM EDT > To: Multiple recipients of list > Subject: NIST Identity-Based Encryption Workshop- Registration > Deadline Approaching > Reply-To: ibe@nist.gov > > > Applications of Pairing-Based Cryptography: Identity-Based > Encryption and Beyond > June 3-4, 2008 > NIST, Gaithersburg, MD > > The early registration deadline is approaching! Please join us at > the workshop and help NIST direct its future work on identity-based > encryption. > > This workshop brings together academia, government and industry to > explore innovative and practical applications of pairing-based > cryptography. Pairings have been used to create identity-based > encryption schemes, but are also a powerful tool for solving other > cryptographic problems. We hope to encourage the development of > new security applications and communication between researchers, > developers and users. In addition to presentations, the workshop > will facilitate panel discussions among invited experts and > workshop participants. NIST will seek guidance from workshop > presenters, panelists and attendees to direct its future work in > this area of cryptography, including possible standards work. > > Dr. Matt Franklin, co-inventor of one of the original identity- > based encryption schemes, will be presenting a keynote address > entitled "An Introduction to Identity Based Encryption." Dr. Brent > Waters will be presenting a keynote address entitled "Functional > Encryption: Beyond Public Key Cryptography." The workshop program > also includes two panel discussions and 13 presentations from > researchers from around the world. The complete agenda has been > posted at http://www.nist.gov/ibe. > > The early registration deadline for the NIST Applications of > Pairing Based Cryptography workshop is quickly approaching. The > registration fee is $110 until May 10th, and $145 until May 27th. > Please note that these fees have been reduced due to NIST no longer > being able to provide food and beverages. Voltage Security and > Trend Micro will be sponsoring the morning and afternoon breaks. > However, each attendee will be responsible for his/her own lunch. > NIST has a full-service cafeteria adjacent to the Green Auditorium. > Please note the cafeteria does not take any credit or debit cards. > Please be prepared with cash. > > More details on the workshop are available at http://www.nist.gov/ibe > > > 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 m46LTj8X039168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 May 2008 14:29: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 m46LTjJa039166; Tue, 6 May 2008 14:29: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.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m46LThw7039143 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Tue, 6 May 2008 14:29:44 -0700 (MST) (envelope-from trevorf@exchange.microsoft.com) Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) by DF-GWY-07.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 6 May 2008 14:30:19 -0700 Received: from df-mlt-02.exchange.corp.microsoft.com (157.54.94.20) by df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 6 May 2008 14:30:19 -0700 Received: from DF-MBX-61.exchange.corp.microsoft.com ([169.254.2.227]) by DF-MLT-02.exchange.corp.microsoft.com ([157.54.94.20]) with mapi; Tue, 6 May 2008 14:30:17 -0700 From: Trevor Freeman To: Jim Schaad , "ietf-smime@imc.org" Date: Tue, 6 May 2008 21:29:34 +0000 Subject: RE: weak authentication issue with rfc5083 Thread-Topic: weak authentication issue with rfc5083 Thread-Index: Aciu6YBkwNV9yBxhQNWEO1d1mLywFgABCUHgAAAYJfAAAU9AUAADVTBQAAAPh/AAK7AMYAACpw8g Message-ID: References: <12c801c8aeed$ddd47670$997d6350$@com> <130901c8af00$b698b0e0$23ca12a0$@com> <14c601c8afaf$af919370$0eb4ba50$@com> In-Reply-To: <14c601c8afaf$af919370$0eb4ba50$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_F767238E699C2E43895DDFB5F435088F0C2C102509DFMBX61exchan_" MIME-Version: 1.0 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_000_F767238E699C2E43895DDFB5F435088F0C2C102509DFMBX61exchan_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The same is true of the MAC because that is sent as unauthenticated data. T= he recipients computes the MAC then compares it to the unprotected value se= nt with the message. The computed value and the transmitted value have to m= atch otherwise it's an authentication failure. If you strip or alter the M= AC the recipient detects problem. This proposal has exactly the same characteristics. Trevor From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Tuesday, May 06, 2008 12:31 PM To: Trevor Freeman; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 I would have an issue with this since could be silently stripped without th= e recipients or senders knowledge. Thus I don't see it as solving your pro= blem. Jim From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 3:42 PM To: Jim Schaad; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Not if you send the recipient info's with the encrypted hmac as an unauthen= ticated attribute. Trevor From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, May 05, 2008 3:38 PM To: Trevor Freeman; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 The downside of this would be that you could no longer do one pass encoding= . You would need to compute the HMAC prior to computing the recipient info= s. Jim From: Trevor Freeman [mailto:trevorf@exchange.microsoft.com] Sent: Monday, May 05, 2008 2:03 PM To: Trevor Freeman; Jim Schaad; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Another suggestion is to use the kek to wrap the hmac just like you wrapped= the CEK. From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 1:40 PM To: Jim Schaad; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Hi Jim, You can demonstrate knowledge of both HMAC and KEK fairly simply per recipi= ent e.g. by concatenating the KEK with the message HMAC and hashing the res= ult. Since Mallet does not know the KEK they cannot compute the new hash. T= his fix works for both 3852 and 5083. Trevor From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, May 05, 2008 1:23 PM To: Trevor Freeman; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Trevor, The same issue also occurs for AuthenticatedData in RFC 3852. This has bee= n known for a long time. I am not sure how a demonstration of the KEK would solve this issue however= . The only way that I know to actually deal with this problem is to place = the computed MAC under encryption for each recipient. Jim From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 12:52 PM To: ietf-smime@imc.org Subject: weak authentication issue with rfc5083 We have identified a potential for spoofing when using rfc5083. Rfc5083 computes a message HMAC over the content using the authenticated en= cryption algorithms. The message HMAC is calculated based on the content an= d the content encryption key (CEK). A number of allowed key management techniques derive a key encryption key (= KEK) which can be used to authenticate the sender e.g. Static-Static Diffie= Hellman, Kerberos shared secret, shared password. The KEK is used to encry= pt the CEK per recipient. However when the integrity of the message is validated via the message HMAC= , the sender only demonstrates knowledge of the CEK to the recipient. Any other recipient knows the CEK so can construct another message using th= e same CEK and compute the new HMAC and reuse the encrypted KEK data from t= he original message. For example: Alice sends a message to Bob and Mallet. Alice uses different KEK's for b= oth Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using his KEK.= The message decrypts and the HMAC checks out so Bob think the message is f= rom Alice because only Bob and Alice know the KEK. Mallet is the recipient of the original message so he can use his KEK to le= arn the message CEK. Mallet then constructs a new message and encrypts it = using the same CEK as the original message. Mallet copies Bobs KEK recipie= nt Info from Alice's message which contains the same encrypted CEK. Because= Mallet knows the CEK he can also compute the correct HMAC for the new mess= age. Mallet sends the new message to Bob. Bob again uses his KEK to discove= r the CEK and successfully decrypts the message and the HMAC check out so B= ob thinks this new message is also from Alice. This issue only applies when there are multiple recipients. The motivation = to use the new authenticated encryption is to improve performance so soluti= ons like bifurcating messages to use different CEK or signing the message a= re counterproductive. We need an additional structure to allow the sender to demonstrate knowledg= e of both the KEK and CEK per recipient when sending to multiple recipients= . What is the consensus to resolve this? We can version 5083 to document the new structure or we can do document the= new structure via a standalone document. --_000_F767238E699C2E43895DDFB5F435088F0C2C102509DFMBX61exchan_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The same is true of the = MAC because that is sent as unauthenticated data. The recipients computes the MAC then compares it to the unprotected value sent with the message. The computed va= lue and the transmitted value have to match otherwise it’s an authenticat= ion failure.  If you strip or alter the MAC the recipient detects problem.

This proposal has exactl= y the same characteristics.

 =

Trevor=

 =

From: Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Tuesday, May 06, 2008 12:31 PM
To: Trevor Freeman; ietf-smime@imc.org
Subject: RE: weak authentication issue with rfc5083

 

I would have an issue wi= th this since could be silently stripped without the recipients or senders knowledg= e.  Thus I don’t see it as solving your problem.<= /p>

 =

Jim

 =

 =

From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 3:42 PM
To: Jim Schaad; ietf-smime@imc.org
Subject: RE: weak authentication issue with rfc5083

 

Not if you send the reci= pient info’s with the encrypted hmac as an unauthenticated attribute.<= /o:p>

 =

Trevor=

 =

From: Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Monday, May 05, 2008 3:38 PM
To: Trevor Freeman; ietf-smime@imc.org
Subject: RE: weak authentication issue with rfc5083

 

The downside of this wou= ld be that you could no longer do one pass encoding.  You would need to comp= ute the HMAC prior to computing the recipient infos.

 =

Jim

 =

 =

From: Trevor Freema= n [mailto:trevorf@exchange.microsoft.com]
Sent: Monday, May 05, 2008 2:03 PM
To: Trevor Freeman; Jim Schaad; ietf-smime@imc.org
Subject: RE: weak authentication issue with rfc5083

 

Another suggestion is to= use the kek to wrap the hmac just like you wrapped the CEK.

 =

From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 1:40 PM
To: Jim Schaad; ietf-smime@imc.org
Subject: RE: weak authentication issue with rfc5083

 

Hi Jim,

You can demonstrate know= ledge of both HMAC and KEK fairly simply per recipient e.g. by concatenating the KEK with the message HMAC and hashing the result. Since Mallet does not know th= e KEK they cannot compute the new hash. This fix works for both 3852 and 5083= .

 =

Trevor=

 =

From: Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Monday, May 05, 2008 1:23 PM
To: Trevor Freeman; ietf-smime@imc.org
Subject: RE: weak authentication issue with rfc5083

 

Trevor,

 =

The same issue also occu= rs for AuthenticatedData in RFC 3852.  This has been known for a long time.

 =

I am not sure how a demonstration of the KEK would solve this issue however.  The only way that I know to actually deal with this problem is to place the computed MAC under encryption for each recipient.

 =

Jim

 =

 =

From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 12:52 PM
To: ietf-smime@imc.org
Subject: weak authentication issue with rfc5083

 

We have identified a potential for spoofing when using rfc5083.

 

Rfc5083 computes a message HMAC over the content using= the authenticated encryption algorithms. The message HMAC is calculated based o= n the content and the content encryption key (CEK).

 

A number of allowed key management techniques derive a= key encryption key (KEK) which can be used to authenticate the sender e.g. Static-Static Diffie Hellman, Kerberos shared secret, shared password. The = KEK is used to encrypt the CEK per recipient.

 

However when the integrity of the message is validated= via the message HMAC, the sender only demonstrates knowledge of the CEK to the recipient.

 

Any other recipient knows the CEK so can construct ano= ther message using the same CEK and compute the new HMAC and reuse the encrypted= KEK data from the original message. For example:

 

Alice sends a message to Bob and Mallet. Alice uses  different KEK’s  for both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using  his KEK. The message decrypts and the HMAC checks out so Bob th= ink the message is from Alice because only Bob and Alice know the KEK.

 

Mallet is the recipient of the original message so he can use his KEK to learn the message CEK. Mallet then  constructs a new message and encrypts it usi= ng the same CEK as the original message. Mallet copies Bobs  KEK recipien= t Info from Alice's message which contains the same encrypted CEK. Because Ma= llet knows the CEK he can also compute the correct HMAC for the new message. Mal= let sends the new message to Bob. Bob again uses his KEK to discover the CEK an= d successfully decrypts the message and the HMAC check out so Bob thinks this= new message is also from Alice.

 

This issue only applies when there are multiple recipients. The motivation to us= e the new authenticated encryption is to improve performance so solutions lik= e bifurcating messages to use different CEK or signing the message are counterproductive.

 

We need an additional structure to allow the sender to demonstrate knowledge of both the KEK and CEK per recipient when sending to multiple recipients.

What is the consensus to resolve this?

 

We can version 5083 to document the new structure or w= e can do document the new structure via a standalone document.

--_000_F767238E699C2E43895DDFB5F435088F0C2C102509DFMBX61exchan_-- 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 m46Ksg8G024071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 May 2008 13:54:42 -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 m46KsgeK024069; Tue, 6 May 2008 13:54:42 -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.202] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m46KsdQu024048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 May 2008 13:54:40 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 6 May 2008 13:54:37 -0700 To: ietf-smime@imc.org From: Paul Hoffman Subject: Patent disclosure of interest Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 m46JUppJ087726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 May 2008 12:30: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 m46JUpic087725; Tue, 6 May 2008 12:30: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 smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m46JUnQW087709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 6 May 2008 12:30:50 -0700 (MST) (envelope-from ietf@augustcellars.com) Received: from GALATIONS (unknown [207.202.179.27]) by smtp2.pacifier.net (Postfix) with ESMTP id 82B7E6B388; Tue, 6 May 2008 12:30:47 -0700 (PDT) From: "Jim Schaad" To: "'Trevor Freeman'" , References: <12c801c8aeed$ddd47670$997d6350$@com> <130901c8af00$b698b0e0$23ca12a0$@com> In-Reply-To: Subject: RE: weak authentication issue with rfc5083 Date: Tue, 6 May 2008 12:30:47 -0700 Message-ID: <14c601c8afaf$af919370$0eb4ba50$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_14C7_01C8AF75.0332BB70" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aciu6YBkwNV9yBxhQNWEO1d1mLywFgABCUHgAAAYJfAAAU9AUAADVTBQAAAPh/AAK7AMYA== Content-Language: en-us Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. ------=_NextPart_000_14C7_01C8AF75.0332BB70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I would have an issue with this since could be silently stripped without the recipients or senders knowledge. Thus I don't see it as solving your problem. Jim From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 3:42 PM To: Jim Schaad; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Not if you send the recipient info's with the encrypted hmac as an unauthenticated attribute. Trevor From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, May 05, 2008 3:38 PM To: Trevor Freeman; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 The downside of this would be that you could no longer do one pass encoding. You would need to compute the HMAC prior to computing the recipient infos. Jim From: Trevor Freeman [mailto:trevorf@exchange.microsoft.com] Sent: Monday, May 05, 2008 2:03 PM To: Trevor Freeman; Jim Schaad; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Another suggestion is to use the kek to wrap the hmac just like you wrapped the CEK. From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 1:40 PM To: Jim Schaad; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Hi Jim, You can demonstrate knowledge of both HMAC and KEK fairly simply per recipient e.g. by concatenating the KEK with the message HMAC and hashing the result. Since Mallet does not know the KEK they cannot compute the new hash. This fix works for both 3852 and 5083. Trevor From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, May 05, 2008 1:23 PM To: Trevor Freeman; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Trevor, The same issue also occurs for AuthenticatedData in RFC 3852. This has been known for a long time. I am not sure how a demonstration of the KEK would solve this issue however. The only way that I know to actually deal with this problem is to place the computed MAC under encryption for each recipient. Jim From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 12:52 PM To: ietf-smime@imc.org Subject: weak authentication issue with rfc5083 We have identified a potential for spoofing when using rfc5083. Rfc5083 computes a message HMAC over the content using the authenticated encryption algorithms. The message HMAC is calculated based on the content and the content encryption key (CEK). A number of allowed key management techniques derive a key encryption key (KEK) which can be used to authenticate the sender e.g. Static-Static Diffie Hellman, Kerberos shared secret, shared password. The KEK is used to encrypt the CEK per recipient. However when the integrity of the message is validated via the message HMAC, the sender only demonstrates knowledge of the CEK to the recipient. Any other recipient knows the CEK so can construct another message using the same CEK and compute the new HMAC and reuse the encrypted KEK data from the original message. For example: Alice sends a message to Bob and Mallet. Alice uses different KEK's for both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using his KEK. The message decrypts and the HMAC checks out so Bob think the message is from Alice because only Bob and Alice know the KEK. Mallet is the recipient of the original message so he can use his KEK to learn the message CEK. Mallet then constructs a new message and encrypts it using the same CEK as the original message. Mallet copies Bobs KEK recipient Info from Alice's message which contains the same encrypted CEK. Because Mallet knows the CEK he can also compute the correct HMAC for the new message. Mallet sends the new message to Bob. Bob again uses his KEK to discover the CEK and successfully decrypts the message and the HMAC check out so Bob thinks this new message is also from Alice. This issue only applies when there are multiple recipients. The motivation to use the new authenticated encryption is to improve performance so solutions like bifurcating messages to use different CEK or signing the message are counterproductive. We need an additional structure to allow the sender to demonstrate knowledge of both the KEK and CEK per recipient when sending to multiple recipients. What is the consensus to resolve this? We can version 5083 to document the new structure or we can do document the new structure via a standalone document. ------=_NextPart_000_14C7_01C8AF75.0332BB70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would have an issue = with this since could be silently stripped without the recipients or senders = knowledge.  Thus I don’t see it as solving your problem.

 

Jim

 

 

From:= owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 3:42 PM
To: Jim Schaad; ietf-smime@imc.org
Subject: RE: weak authentication issue with = rfc5083

 

Not if you send the = recipient info’s with the encrypted hmac as an unauthenticated = attribute.

 

Trevor

 

From:= Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Monday, May 05, 2008 3:38 PM
To: Trevor Freeman; ietf-smime@imc.org
Subject: RE: weak authentication issue with = rfc5083

 

The downside of this = would be that you could no longer do one pass encoding.  You would need to = compute the HMAC prior to computing the recipient infos.

 

Jim

 

 

From:= Trevor = Freeman [mailto:trevorf@exchange.microsoft.com]
Sent: Monday, May 05, 2008 2:03 PM
To: Trevor Freeman; Jim Schaad; ietf-smime@imc.org
Subject: RE: weak authentication issue with = rfc5083

 

Another suggestion is = to use the kek to wrap the hmac just like you wrapped the = CEK.

 

From:= owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 1:40 PM
To: Jim Schaad; ietf-smime@imc.org
Subject: RE: weak authentication issue with = rfc5083

 

Hi = Jim,

You can demonstrate = knowledge of both HMAC and KEK fairly simply per recipient e.g. by concatenating the = KEK with the message HMAC and hashing the result. Since Mallet does not know = the KEK they cannot compute the new hash. This fix works for both 3852 and = 5083.

 

Trevor

 

From:= Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Monday, May 05, 2008 1:23 PM
To: Trevor Freeman; ietf-smime@imc.org
Subject: RE: weak authentication issue with = rfc5083

 

Trevor,

 

The same issue also = occurs for AuthenticatedData in RFC 3852.  This has been known for a long = time.

 

I am not sure how a = demonstration of the KEK would solve this issue however.  The only way that I = know to actually deal with this problem is to place the computed MAC under = encryption for each recipient.

 

Jim

 

 

From:= owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 12:52 PM
To: ietf-smime@imc.org
Subject: weak authentication issue with = rfc5083

 

We have identified a potential for spoofing when = using rfc5083.

 

Rfc5083 computes a message HMAC over the content = using the authenticated encryption algorithms. The message HMAC is calculated = based on the content and the content encryption key (CEK).

 

A number of allowed key management techniques = derive a key encryption key (KEK) which can be used to authenticate the sender e.g. Static-Static Diffie Hellman, Kerberos shared secret, shared password. = The KEK is used to encrypt the CEK per recipient.

 

However when the integrity of the message is = validated via the message HMAC, the sender only demonstrates knowledge of the CEK to = the recipient.

 

Any other recipient knows the CEK so can construct = another message using the same CEK and compute the new HMAC and reuse the = encrypted KEK data from the original message. For example:

 

Alice sends a message to Bob and Mallet. Alice uses  different = KEK’s  for both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using  = his KEK. The message decrypts and the HMAC checks out so Bob think the = message is from Alice because only Bob and Alice know the = KEK.

 =

Mallet is the recipient of the original message so he can use his KEK to learn = the message CEK. Mallet then  constructs a new message and encrypts it = using the same CEK as the original message. Mallet copies Bobs  KEK = recipient Info from Alice's message which contains the same encrypted CEK. Because = Mallet knows the CEK he can also compute the correct HMAC for the new message. = Mallet sends the new message to Bob. Bob again uses his KEK to discover the CEK = and successfully decrypts the message and the HMAC check out so Bob thinks = this new message is also from Alice.

 =

This issue only applies when there are multiple recipients. The motivation to = use the new authenticated encryption is to improve performance so solutions = like bifurcating messages to use different CEK or signing the message are = counterproductive.

 

We need an additional structure to allow the sender = to demonstrate knowledge of both the KEK and CEK per recipient when sending = to multiple recipients.

What is the consensus to resolve this? =

 

We can version 5083 to document the new structure = or we can do document the new structure via a standalone document.

------=_NextPart_000_14C7_01C8AF75.0332BB70-- 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 m46JTmZp087269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 May 2008 12:29:48 -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 m46JTmHW087268; Tue, 6 May 2008 12:29:48 -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 m46JTkf5087251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 6 May 2008 12:29:48 -0700 (MST) (envelope-from ietf@augustcellars.com) Received: from GALATIONS (unknown [207.202.179.27]) by smtp4.pacifier.net (Postfix) with ESMTP id 0FCDC6A586; Tue, 6 May 2008 12:29:43 -0700 (PDT) From: "Jim Schaad" To: "'Peter Gutmann'" , , References: In-Reply-To: Subject: RE: weak authentication issue with rfc5083 Date: Tue, 6 May 2008 12:29:43 -0700 Message-ID: <14c501c8afaf$899e2700$9cda7500$@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: AcivRWhy9LBxPdCQTUOMP8nN1uv26gAab23A Content-Language: en-us Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter, I believe you have misunderstood the issue that Trevor raised. His problem is: 1. I send you and him a single Authenticated Message. 2. He takes the common CEK in the original message, uses it to create a MAC on an new message and then sends it on to you. As is always true with Authenticated messages, there is no proof of origin. He worries that you might be confused and believe the second messages was from me rather than from him. Since they both use the same CEK that is not a factor that could be used to distinguish them. Jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf- > smime@mail.imc.org] On Behalf Of Peter Gutmann > Sent: Monday, May 05, 2008 11:47 PM > To: ietf-smime@imc.org; trevorf@EXCHANGE.MICROSOFT.com > Subject: Re: weak authentication issue with rfc5083 > > > Trevor Freeman writes: > > >However when the integrity of the message is validated via the message > HMAC, > >the sender only demonstrates knowledge of the CEK to the recipient. > > > >Any other recipient knows the CEK so can construct another message > using the > >same CEK and compute the new HMAC and reuse the encrypted KEK data > from the > >original message. For example: > > Uhh, AuthEnv doesn't specify any use of HMAC, it can be used with HMAC > if > required (the other use is with a combined MAC+encrypt mode), but in > the HMAC > usage the HMAC and CEK keys are derived from a single key using a PRF, > so > knowledge of the CEK doesn't give you the HMAC key, and vice versa. It > was > specifically designed that way to prevent rollbacks where you strip off > the > MAC and rewrite it as plain encrypted data. Or have I misunderstood > your > point? > > Peter. 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 m46JPA9L085140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 May 2008 12:25:10 -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 m46JPA48085139; Tue, 6 May 2008 12:25:10 -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.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m46JP8Cr085117 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Tue, 6 May 2008 12:25:09 -0700 (MST) (envelope-from trevorf@exchange.microsoft.com) Received: from df-bhd-01.exchange.corp.microsoft.com (157.54.111.57) by DF-GWY-07.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 6 May 2008 12:25:49 -0700 Received: from df-mlt-02.exchange.corp.microsoft.com (157.54.94.20) by df-bhd-01.exchange.corp.microsoft.com (157.54.111.57) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 6 May 2008 12:25:49 -0700 Received: from DF-MBX-61.exchange.corp.microsoft.com ([169.254.2.227]) by DF-MLT-02.exchange.corp.microsoft.com ([157.54.94.20]) with mapi; Tue, 6 May 2008 12:25:48 -0700 From: Trevor Freeman To: pgut001 , "ietf-smime@imc.org" Date: Tue, 6 May 2008 19:25:05 +0000 Subject: RE: weak authentication issue with rfc5083 Thread-Topic: weak authentication issue with rfc5083 Thread-Index: Aciu6YBkwNV9yBxhQNWEO1d1mLywFgAW5sp3ABoHyLA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I should have use MAC to be more accurate. 5083 generates a MAC using the message contents and the CEK. If there are multiple recipients - all know the CEK so any can generate new= messages with the same CEK. So you only can presume the message is from on= e of the group who know the CEK but you don't know which one. You could have used a pair wise shared secret to protect the CEK but 5083 d= oes not define how to use the pair wise shared secret to also authenticate = the sender. If the sender encrypted the MAC using the KEK and attached that= to the message as an unauthenticated attribute the receiver can authentica= te the sender. -----Original Message----- From: pgut001 [mailto:pgut001@cs.auckland.ac.nz] Sent: Monday, May 05, 2008 11:47 PM To: ietf-smime@imc.org; Trevor Freeman Subject: Re: weak authentication issue with rfc5083 Trevor Freeman writes: >However when the integrity of the message is validated via the message HMA= C, >the sender only demonstrates knowledge of the CEK to the recipient. > >Any other recipient knows the CEK so can construct another message using t= he >same CEK and compute the new HMAC and reuse the encrypted KEK data from th= e >original message. For example: Uhh, AuthEnv doesn't specify any use of HMAC, it can be used with HMAC if required (the other use is with a combined MAC+encrypt mode), but in the HM= AC usage the HMAC and CEK keys are derived from a single key using a PRF, so knowledge of the CEK doesn't give you the HMAC key, and vice versa. It was specifically designed that way to prevent rollbacks where you strip off the MAC and rewrite it as plain encrypted data. Or have I misunderstood your point? Peter. 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 m46Hj1sv042368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 May 2008 10:45:01 -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 m46Hj1BM042367; Tue, 6 May 2008 10:45:01 -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 [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m46Hj0dR042357 for ; Tue, 6 May 2008 10:45:01 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 7A69B28C37A; Tue, 6 May 2008 10:45: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-rfc3278-update-04.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080506174501.7A69B28C37A@core3.amsl.com> Date: Tue, 6 May 2008 10:45: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 : Update to Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) Author(s) : S. Turner Filename : draft-ietf-smime-rfc3278-update-04.txt Pages : 28 Date : 2008-5-6 RFC 3278 describes how to use Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic Message Syntax (CMS). This document updates RFC 3278 to add support for the SHA2 family of hash algorithms, Elliptic Curve Digital Signature Algorithm (ECDSA) 224-512, and Key Derivation Functions (KDFs) that utilize SHA2 algorithms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc3278-update-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. --NextPart Content-Type: Message/External-body; name="draft-ietf-smime-rfc3278-update-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-5-6103457.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 m46H3bXf025804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 May 2008 10:03: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 m46H3bia025803; Tue, 6 May 2008 10:03: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 smtp109.biz.mail.re2.yahoo.com (smtp109.biz.mail.re2.yahoo.com [206.190.53.8]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m46H3avB025788 for ; Tue, 6 May 2008 10:03:36 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 62523 invoked from network); 6 May 2008 16:41:25 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.241.4.90 with login) by smtp109.biz.mail.re2.yahoo.com with SMTP; 6 May 2008 16:41:25 -0000 X-YMail-OSG: VN59W1QVM1kYaRMsqcNsLGjjtHSuRqGwU77yI.XRc.EtcTB9fgSNWUI4NoHwALnlS450vXQkq8EDX2Xe19kGExRsKVVsB9x5ksvm7rbj2B69_1ZhjaPSBH84um84jY4pRCw- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "'Tony Capel'" , "'Paul Hoffman'" , References: <023701c8aef2$ad31a650$0201a8c0@Wylie> <004301c8aef7$bcafeba0$02b5a8c0@tony> Subject: RE: S/MIME v3.2 IDs key size text Date: Tue, 6 May 2008 12:37:19 -0400 Organization: IECA, Inc. Message-ID: <025e01c8af97$73f5a4e0$0201a8c0@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.3198 In-Reply-To: <004301c8aef7$bcafeba0$02b5a8c0@tony> Thread-Index: AcitjLJkvgon3zgMT46W137Z98cRiQBUq31QAASyTyAAAQJGwAAhkymw Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tony, Inline... spt >-----Original Message----- >From: owner-ietf-smime@mail.imc.org >[mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Tony Capel >Sent: Monday, May 05, 2008 5:34 PM >To: 'Turner, Sean P.'; 'Paul Hoffman'; ietf-smime@imc.org >Subject: RE: S/MIME v3.2 IDs key size text > > >Sean: > >Agreed, the text in 3850bis and 3851bis needs to align. I >have no problems with support for smaller key sizes. You got it. I was just trying to say we need to keep the two algined. >I expect constraints on key size to be implemented by the >certificate issuer anyway. If you get a 512 key in a cert you >trust you must be able to use it, no? Originally, I thought the answer really was no, but I think for interop with v3 and v3.1 we need to say yes. If you get a 512 key in a cert from a source you trust, then you can decide to not use it but it's not because you don't trust the source it's because of some other reason. I can see where maybe short lived certs are used because the info gets stale quickly, they need to sign/verify really quickly, etc. I am a little concerned about the FIP-140 issue though. Just a thought ... since we've now got a way to indicate + and - with requirements should we apply it the key sizes in 3850bis? That way people will have a hint that in the next update the shorter keys will likely become not so welcome and large keys more so? 0 < key size < 511 : MUST NOT 512 < key size < 1023 : SHOULD- 1024 < key size < 2048 : MUST 2049 < key size < 4096 : MAY >Tony > >| -----Original Message----- >| From: owner-ietf-smime@mail.imc.org >| [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Turner, Sean P. >| Sent: May 5, 2008 4:58 PM >| To: 'Tony Capel'; 'Paul Hoffman'; ietf-smime@imc.org >| Subject: RE: S/MIME v3.2 IDs key size text >| >| >| >| Tony, >| >| There was a comment from Paul against the text you cite from >3850bis. >| He objected to moving the lower bounds from 512 to 1024. I >figured I'd >| post both -02 drafts once we knocked this issue out. >| >| spt >| >| >-----Original Message----- >| >From: Tony Capel [mailto:capel@comgate.com] >| >Sent: Monday, May 05, 2008 4:09 PM >| >To: 'Paul Hoffman'; 'Turner, Sean P.'; ietf-smime@imc.org >| >Subject: RE: S/MIME v3.2 IDs key size text >| > >| >All: >| > >| >I agree that deleting " namely 1024 bits" from the first >sentence of >| >the proposed security considerations section paragraph is >good. The >| >second "1024" >| >in the proposed paragraph is not a problem for me since it is not >| >"normative". >| > >| >With respect to section 4.1 (Key Pair Generation). Is it >intended to >| >change the title of this section? The second paragraph of the >| >current text in 3851bis-01.txt begins "If an S/MIME agent needs to >| >generate ...". So if the S/MIME agent does NOT need to >generate keys >| >(and this is typically the case, most enrollment & key >generation are >| >done externally to messaging clients) the balance of this paragraph >| >(which mentions the key sizes) is not normative (as >currently drafted >| >- its quite possible that the last sentence of this >paragraph should >| >have been in a separate paragraph). Key generation >requirements are >| >normally (hopefully!) cited in the corresponding CP, where things >| >such as required key sizes, where they are generated (locally or at >| >the CA), FIPS-140 Level, etc. should be (!!) explicitly >identified. >| >Maybe the second paragraph of >| >4.1 could be replaced with a simple statement: >| > >| >"If an S/MIME agent needs to generate one or more key pairs, each >| >SHOULD be generated according to the corresponding certificate >| >policy, refer for example to [RFC3647]." >| > >| >The proposed text, and the discussion so far, is really speaking >| >about "what range of RSA key sizes" needs to be supported. We are >| >NOT providing security advice, we are just trying to ensure >that most >| >smime v3.2 implementations will interwork in the typical >environments >| >expected "in the wild" >| >(and special environments will be understood by purchasers >anyway, so >| >we likely need not worry about high security applications - >only the >| >general "public" >| >environments). >| > >| >A similar issue is already addressed in CERT v3.2 ( >| >draft-ietf-smime-3850bis-01.txt ) in Section 4.3 for certificate >| >validation. >| >We might consider copying the last sentence of CERT v3.2 Sec >| >4.3 to the end of sections 2.2 and 2.3 (just before the Notes): >| > >| > "Key sizes from 1024 bits to 2048 bits MUST be supported." >| > >| >This would also have the advantage of aligning CERT and MSG. >| > >| >Tony >| > >| > >| >| -----Original Message----- >| >| From: owner-ietf-smime@mail.imc.org >| >| [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Paul Hoffman >| >| Sent: May 3, 2008 10:08 PM >| >| To: Turner, Sean P.; ietf-smime@imc.org >| >| Subject: RE: S/MIME v3.2 IDs key size text >| >| >| >| >| >| >| >| At 8:51 PM -0400 5/3/08, Turner, Sean P. wrote: >| >| >I think if we struck ", namely 1024 bits" from the text in >| >| the security >| >| >considerations that it's still a true statement and we >| >won't have to >| >| >change it every time we update the spec. >| >| >| >| I'm OK with that, but I also feel that if we're updating >| the minimum >| >| mandatory signing length, it is trivial to update the Security >| >| Considerations as well. >| >| >| > >| > 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 m46GE8Ub004569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 May 2008 09:14: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 m46GE8FC004568; Tue, 6 May 2008 09:14: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 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 m46GE6Fx004551 for ; Tue, 6 May 2008 09:14:07 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 66171 invoked from network); 6 May 2008 16:13:55 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.241.4.90 with login) by smtp110.biz.mail.re2.yahoo.com with SMTP; 6 May 2008 16:13:55 -0000 X-YMail-OSG: u31WUQsVM1nVkZHTpNgj6yrTLx9AFLV8.eHejJp6UkRWNNMutuX_YfvCEkg6bah_KrlXItqWROCOOYEVlG5DLm_7bvkqmIOqWw59MtTXoc7w1IpQxd3ckwboniqEwtSH9v4- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "'Jim Schaad'" , "'Ietf-Smime'" References: <018301c8a3cb$38074bf0$0301a8c0@Wylie> <0fe601c8ad70$57e77c70$07b67550$@com> Subject: RE: New ASN.1 modules comments/questions Date: Tue, 6 May 2008 12:09:49 -0400 Organization: IECA, Inc. Message-ID: <025b01c8af93$9c6d6f10$0201a8c0@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.3198 In-Reply-To: <0fe601c8ad70$57e77c70$07b67550$@com> Thread-Index: Acijyzeq0RMiwCJnRHiuFMdEY7uJtQJkneRgAIucnJA= Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jim, No worries on the delay. Some thoughts on your responses. spt >> The definitions of AlgorithmIdentifier in the PKIX and SMIME modules >> are different - is there a reason for the difference? Does >it matter? >> In PKIX it's AlgorithmSet, in SMIME it's InfoObjectSet, in RFC2976 >> it's IOSet, in ANSI X9 docs it's also IOSet, and in X.509 it's >> SupportedAlgorithms. If it matters, then I guess I lean >towards what's >> in RFC2976 since it's already in an RFC. > >There is no effective difference between the two definitions. >The two differences are 1) the name of a parameter and 2) >comments. The name of the parameter makes no difference. >Just as the name of a parameter makes no difference if you are >writing a C function. The same is true for comments. I figured as much, but if we can control it I think they should be called the same thing. Don't really care what it's called just that they're called the same thing. >> ------------------- >> >> In the 3370 section, >> >> 2. You used alg- as tag for hash algs, sig- for signature >algs, kea- >> for key agreement algs, alg- for symmetric key encryption algs. I >> think it might be easier to figure out which algs go where >if the tag >> matches the type of algorithm like mda- for MessageDigestAlgorithms, >> sa- for SignatureAlgorithms, and kaa- for KeyAgreementAlgorithms. > >Thanks for suggesting some potential tags to be used. I agree >that we need some short simple notation to mark the different >types of algorithm objects. Since I'm using some of these tags in other IDs, I'll try to make sure we're in synch. >> 3. Could we change SymmetricKeyEncryptionAlgorithms to just >> KeyWrapAlgorithms and use kwa- as the tag? There's also a >> KeyWrapAlgorithm that I think is supposed to be the same as the >> SymmetricKeyEncryptionAlgorithms so one or the other can get deleted >> (if you delete the later change SupportKeyWrapAlgorithms to >> KeyWrapAlgorithms)? > >I have no problems with this change. There is a minor >question here about doing a good job of distinguishing Key >Wrap Algorithms and Key Transport Algorithms. > >I added the Symmetric to the front to distinguish from Key >Transport algorithms which, as the KEA algorithm suggest, can >also be thought of as >Key Encryption algorithms. The use of Key Wrap might be >sufficient to >distinguish between them, but CMS uses Key Encryption as the >name of these types of algorithms. > >Which is a better way to go? I think it's a toss up. I guess I was just confused because it wasn't clear to me whether the keyEncryptionAlgorithm in 3852 was constrainted by SymmetricKeyEncryption or KeyWrapAlgorithm. Now that I think about it the KeyWrapAlgorithms in this module is used to define the algorithm. This makes me think that adding comments above each IOset to say what it's constraining would help the reader a lot. >> 4. Shouldn't SymmetricKeyEncryptionAlgorithms be extensible? >> > >Welcome to a long philosophical discussion. > >There are two different places where this extensibility can be >placed. The two different locations imply different things. >This means that depending on how you look at things this >should or should not be extensible. > >If you place the extensibility here, you are saying that we >think that this document is going to be updated, and that we >are going to add new algorithms to this document. > >Alternatively, if you place the extensibility in CMS, you are >saying that we are going to define new algorithms by creating >new documents with new modules and they should be "imported" >into the CMS document in one manner or another. > >The compiler that we are working on has a planned directive to >allow for an object to be added to an extensible object set. >Part of the question at this point would be as follows. Where >should the new algorithm be added, in this document - thus >potentially effecting more than just CMS - or in CMS thus >limiting where the changes are set. > >My personal beliefs are: >- 1. New algorithms should be added by creating new documents >not by updating this document >- 2. Changes in algorithm sets should be as narrow as >possible - thus the updates should be done in CMS not here. > >The upshot of this is that I believe this object set is NOT >extensible, but the corresponding one in CMS should be extensible. I agree with you. We're already on this track because we've not updated 3370 every time a new alg comes along - what we've done is define a new ID with a new module. Don't see any reason to change from that course. >> ------------------- >> >> In the 3852 section, >> >> 2. Are you going to remove the version notations [[3:, [[4:, etc? > >It is my belief that having the version tags included adds >information to the ASN.1 module. Thus I plan on keeping them >unless I get some large objections. Still thinking about whether I should object ;) >> 3. For consistency with 3370, can we change DigestAlgorithmList to >> MessageDigestAlgorithms? > >I don't want these to have the same names. In the long run we >will do the >following: > DigestAlgorithmList ALGORITHM ::= {MessageDigestAlgorithms,...} > > >However I am open to the following: >- We create a standardized but descriptive method of naming >the sets of algorithms defined in a module - thus in 3370 we might say > CMSAlgs-MessageDigestAlgorithm > >- Do the suggested re-name here. Okay >> 10. For consistency, can we change KeyEncryptionAlgorithmList to be >> KeyEncryptionAlgorithms? > >The above note about matching the name in 3370 needs to be >taken into account. I used List (but could have used Set) but >I am not wedded to this. >I worry about using an 's' at the end as this could be a >sequence of algorithms as well. There exists a potential >confusion in the future. Sometimes we've used an 's' sometimes we've used 'list' - I guess I'd like them to be the same for no other reason than consistency. >> ------------------- >> >> In the 4998 section, >> >> 3. Why is Extensions and EXTENSION imported? > >To use a single standardized version, as with Attribute I might have missed it but I don't think it's used in the module? >> ------------------- >> >> In the 5035 section, >> >> 1. Why is Extensions and EXTENSION imported? >> > >See above I might have missed it but I don't think it's used in the module? >> 6. Is the note about the identical SecurityCategories encoding >> required >> anymore? > >I have no opinion one way or the other on this. Being >conservative says it >stays. Okay 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 m466lFJg072766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 23:47: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 m466lFBe072764; Mon, 5 May 2008 23:47: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 mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m466l9c3072736 for ; Mon, 5 May 2008 23:47:14 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 15187187B5; Tue, 6 May 2008 18:47:09 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPrXX8W1JpNt; Tue, 6 May 2008 18:47:08 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 496C0187B3; Tue, 6 May 2008 18:47:08 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 992C1E0808A; Tue, 6 May 2008 18:47:00 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JtGx2-0006Wi-Ff; Tue, 06 May 2008 18:47:00 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org, trevorf@EXCHANGE.MICROSOFT.com Subject: Re: weak authentication issue with rfc5083 In-Reply-To: Message-Id: Date: Tue, 06 May 2008 18:47:00 +1200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Trevor Freeman writes: >However when the integrity of the message is validated via the message HMAC, >the sender only demonstrates knowledge of the CEK to the recipient. > >Any other recipient knows the CEK so can construct another message using the >same CEK and compute the new HMAC and reuse the encrypted KEK data from the >original message. For example: Uhh, AuthEnv doesn't specify any use of HMAC, it can be used with HMAC if required (the other use is with a combined MAC+encrypt mode), but in the HMAC usage the HMAC and CEK keys are derived from a single key using a PRF, so knowledge of the CEK doesn't give you the HMAC key, and vice versa. It was specifically designed that way to prevent rollbacks where you strip off the MAC and rewrite it as plain encrypted data. Or have I misunderstood your point? Peter. 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 m45MfZZn066012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 15:41:35 -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 m45MfZna066011; Mon, 5 May 2008 15:41:35 -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.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.1.17]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m45MfXfm065996 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Mon, 5 May 2008 15:41:34 -0700 (MST) (envelope-from trevorf@exchange.microsoft.com) Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) by DF-GWY-05.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 5 May 2008 15:42:12 -0700 Received: from df-mlt-02.exchange.corp.microsoft.com (157.54.94.20) by df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 5 May 2008 15:42:12 -0700 Received: from DF-MBX-61.exchange.corp.microsoft.com ([169.254.2.227]) by DF-MLT-02.exchange.corp.microsoft.com ([157.54.94.20]) with mapi; Mon, 5 May 2008 15:42:10 -0700 From: Trevor Freeman To: Jim Schaad , "ietf-smime@imc.org" Date: Mon, 5 May 2008 22:41:31 +0000 Subject: RE: weak authentication issue with rfc5083 Thread-Topic: weak authentication issue with rfc5083 Thread-Index: Aciu6YBkwNV9yBxhQNWEO1d1mLywFgABCUHgAAAYJfAAAU9AUAADVTBQAAAPh/A= Message-ID: References: <12c801c8aeed$ddd47670$997d6350$@com> <130901c8af00$b698b0e0$23ca12a0$@com> In-Reply-To: <130901c8af00$b698b0e0$23ca12a0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_F767238E699C2E43895DDFB5F435088F0C2C07BE77DFMBX61exchan_" MIME-Version: 1.0 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_000_F767238E699C2E43895DDFB5F435088F0C2C07BE77DFMBX61exchan_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Not if you send the recipient info's with the encrypted hmac as an unauthen= ticated attribute. Trevor From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, May 05, 2008 3:38 PM To: Trevor Freeman; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 The downside of this would be that you could no longer do one pass encoding= . You would need to compute the HMAC prior to computing the recipient info= s. Jim From: Trevor Freeman [mailto:trevorf@exchange.microsoft.com] Sent: Monday, May 05, 2008 2:03 PM To: Trevor Freeman; Jim Schaad; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Another suggestion is to use the kek to wrap the hmac just like you wrapped= the CEK. From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 1:40 PM To: Jim Schaad; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Hi Jim, You can demonstrate knowledge of both HMAC and KEK fairly simply per recipi= ent e.g. by concatenating the KEK with the message HMAC and hashing the res= ult. Since Mallet does not know the KEK they cannot compute the new hash. T= his fix works for both 3852 and 5083. Trevor From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, May 05, 2008 1:23 PM To: Trevor Freeman; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Trevor, The same issue also occurs for AuthenticatedData in RFC 3852. This has bee= n known for a long time. I am not sure how a demonstration of the KEK would solve this issue however= . The only way that I know to actually deal with this problem is to place = the computed MAC under encryption for each recipient. Jim From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 12:52 PM To: ietf-smime@imc.org Subject: weak authentication issue with rfc5083 We have identified a potential for spoofing when using rfc5083. Rfc5083 computes a message HMAC over the content using the authenticated en= cryption algorithms. The message HMAC is calculated based on the content an= d the content encryption key (CEK). A number of allowed key management techniques derive a key encryption key (= KEK) which can be used to authenticate the sender e.g. Static-Static Diffie= Hellman, Kerberos shared secret, shared password. The KEK is used to encry= pt the CEK per recipient. However when the integrity of the message is validated via the message HMAC= , the sender only demonstrates knowledge of the CEK to the recipient. Any other recipient knows the CEK so can construct another message using th= e same CEK and compute the new HMAC and reuse the encrypted KEK data from t= he original message. For example: Alice sends a message to Bob and Mallet. Alice uses different KEK's for b= oth Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using his KEK.= The message decrypts and the HMAC checks out so Bob think the message is f= rom Alice because only Bob and Alice know the KEK. Mallet is the recipient of the original message so he can use his KEK to le= arn the message CEK. Mallet then constructs a new message and encrypts it = using the same CEK as the original message. Mallet copies Bobs KEK recipie= nt Info from Alice's message which contains the same encrypted CEK. Because= Mallet knows the CEK he can also compute the correct HMAC for the new mess= age. Mallet sends the new message to Bob. Bob again uses his KEK to discove= r the CEK and successfully decrypts the message and the HMAC check out so B= ob thinks this new message is also from Alice. This issue only applies when there are multiple recipients. The motivation = to use the new authenticated encryption is to improve performance so soluti= ons like bifurcating messages to use different CEK or signing the message a= re counterproductive. We need an additional structure to allow the sender to demonstrate knowledg= e of both the KEK and CEK per recipient when sending to multiple recipients= . What is the consensus to resolve this? We can version 5083 to document the new structure or we can do document the= new structure via a standalone document. --_000_F767238E699C2E43895DDFB5F435088F0C2C07BE77DFMBX61exchan_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Not if you send the reci= pient info’s with the encrypted hmac as an unauthenticated attribute.<= /p>

 =

Trevor=

 =

From: Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Monday, May 05, 2008 3:38 PM
To: Trevor Freeman; ietf-smime@imc.org
Subject: RE: weak authentication issue with rfc5083

 

The downside of this wou= ld be that you could no longer do one pass encoding.  You would need to comp= ute the HMAC prior to computing the recipient infos.

 =

Jim

 =

 =

From: Trevor Freema= n [mailto:trevorf@exchange.microsoft.com]
Sent: Monday, May 05, 2008 2:03 PM
To: Trevor Freeman; Jim Schaad; ietf-smime@imc.org
Subject: RE: weak authentication issue with rfc5083

 

Another suggestion is to= use the kek to wrap the hmac just like you wrapped the CEK.

 =

From: owner-ietf-sm= ime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 1:40 PM
To: Jim Schaad; ietf-smime@imc.org
Subject: RE: weak authentication issue with rfc5083

 

Hi Jim,

You can demonstrate know= ledge of both HMAC and KEK fairly simply per recipient e.g. by concatenating the KEK with the message HMAC and hashing the result. Since Mallet does not know th= e KEK they cannot compute the new hash. This fix works for both 3852 and 5083= .

 =

Trevor=

 =

From: Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Monday, May 05, 2008 1:23 PM
To: Trevor Freeman; ietf-smime@imc.org
Subject: RE: weak authentication issue with rfc5083

 

Trevor,

 =

The same issue also occu= rs for AuthenticatedData in RFC 3852.  This has been known for a long time.

 =

I am not sure how a demonstration of the KEK would solve this issue however.  The only way that I know to actually deal with this problem is to place the computed MAC under encryption for each recipient.

 =

Jim

 =

 =

From: owner-ietf-sm= ime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 12:52 PM
To: ietf-smime@imc.org
Subject: weak authentication issue with rfc5083

 

We have identified a potential for spoofing when using rfc5083.

 

Rfc5083 computes a message HMAC over the content using= the authenticated encryption algorithms. The message HMAC is calculated based o= n the content and the content encryption key (CEK).

 

A number of allowed key management techniques derive a= key encryption key (KEK) which can be used to authenticate the sender e.g. Static-Static Diffie Hellman, Kerberos shared secret, shared password. The = KEK is used to encrypt the CEK per recipient.

 

However when the integrity of the message is validated= via the message HMAC, the sender only demonstrates knowledge of the CEK to the recipient.

 

Any other recipient knows the CEK so can construct ano= ther message using the same CEK and compute the new HMAC and reuse the encrypted= KEK data from the original message. For example:

 

Alice sends a message to Bob and Mallet. Alice uses  different KEK’s  for both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using  his KEK. The message decrypts and the HMAC checks out so Bob th= ink the message is from Alice because only Bob and Alice know the KEK.

 

Mallet is the recipient of the original message so he can use his KEK to learn the message CEK. Mallet then  constructs a new message and encrypts it usi= ng the same CEK as the original message. Mallet copies Bobs  KEK recipien= t Info from Alice's message which contains the same encrypted CEK. Because Ma= llet knows the CEK he can also compute the correct HMAC for the new message. Mal= let sends the new message to Bob. Bob again uses his KEK to discover the CEK an= d successfully decrypts the message and the HMAC check out so Bob thinks this= new message is also from Alice.

 

This issue only applies when there are multiple recipients. The motivation to us= e the new authenticated encryption is to improve performance so solutions lik= e bifurcating messages to use different CEK or signing the message are counterproductive.

 

We need an additional structure to allow the sender to demonstrate knowledge of both the KEK and CEK per recipient when sending to multiple recipients.

What is the consensus to resolve this?

 

We can version 5083 to document the new structure or w= e can do document the new structure via a standalone document.

--_000_F767238E699C2E43895DDFB5F435088F0C2C07BE77DFMBX61exchan_-- 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 m45McNq0064653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 15:38:24 -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 m45McNhF064652; Mon, 5 May 2008 15:38: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 smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m45McMwp064644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 5 May 2008 15:38:23 -0700 (MST) (envelope-from ietf@augustcellars.com) Received: from GALATIONS (unknown [207.202.179.27]) by smtp3.pacifier.net (Postfix) with ESMTP id 76D9585A1; Mon, 5 May 2008 15:38:15 -0700 (PDT) From: "Jim Schaad" To: "'Trevor Freeman'" , References: <12c801c8aeed$ddd47670$997d6350$@com> In-Reply-To: Subject: RE: weak authentication issue with rfc5083 Date: Mon, 5 May 2008 15:38:14 -0700 Message-ID: <130901c8af00$b698b0e0$23ca12a0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_130A_01C8AEC6.0A39D8E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aciu6YBkwNV9yBxhQNWEO1d1mLywFgABCUHgAAAYJfAAAU9AUAADVTBQ Content-Language: en-us Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. ------=_NextPart_000_130A_01C8AEC6.0A39D8E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The downside of this would be that you could no longer do one pass encoding. You would need to compute the HMAC prior to computing the recipient infos. Jim From: Trevor Freeman [mailto:trevorf@exchange.microsoft.com] Sent: Monday, May 05, 2008 2:03 PM To: Trevor Freeman; Jim Schaad; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Another suggestion is to use the kek to wrap the hmac just like you wrapped the CEK. From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 1:40 PM To: Jim Schaad; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Hi Jim, You can demonstrate knowledge of both HMAC and KEK fairly simply per recipient e.g. by concatenating the KEK with the message HMAC and hashing the result. Since Mallet does not know the KEK they cannot compute the new hash. This fix works for both 3852 and 5083. Trevor From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, May 05, 2008 1:23 PM To: Trevor Freeman; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Trevor, The same issue also occurs for AuthenticatedData in RFC 3852. This has been known for a long time. I am not sure how a demonstration of the KEK would solve this issue however. The only way that I know to actually deal with this problem is to place the computed MAC under encryption for each recipient. Jim From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 12:52 PM To: ietf-smime@imc.org Subject: weak authentication issue with rfc5083 We have identified a potential for spoofing when using rfc5083. Rfc5083 computes a message HMAC over the content using the authenticated encryption algorithms. The message HMAC is calculated based on the content and the content encryption key (CEK). A number of allowed key management techniques derive a key encryption key (KEK) which can be used to authenticate the sender e.g. Static-Static Diffie Hellman, Kerberos shared secret, shared password. The KEK is used to encrypt the CEK per recipient. However when the integrity of the message is validated via the message HMAC, the sender only demonstrates knowledge of the CEK to the recipient. Any other recipient knows the CEK so can construct another message using the same CEK and compute the new HMAC and reuse the encrypted KEK data from the original message. For example: Alice sends a message to Bob and Mallet. Alice uses different KEK's for both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using his KEK. The message decrypts and the HMAC checks out so Bob think the message is from Alice because only Bob and Alice know the KEK. Mallet is the recipient of the original message so he can use his KEK to learn the message CEK. Mallet then constructs a new message and encrypts it using the same CEK as the original message. Mallet copies Bobs KEK recipient Info from Alice's message which contains the same encrypted CEK. Because Mallet knows the CEK he can also compute the correct HMAC for the new message. Mallet sends the new message to Bob. Bob again uses his KEK to discover the CEK and successfully decrypts the message and the HMAC check out so Bob thinks this new message is also from Alice. This issue only applies when there are multiple recipients. The motivation to use the new authenticated encryption is to improve performance so solutions like bifurcating messages to use different CEK or signing the message are counterproductive. We need an additional structure to allow the sender to demonstrate knowledge of both the KEK and CEK per recipient when sending to multiple recipients. What is the consensus to resolve this? We can version 5083 to document the new structure or we can do document the new structure via a standalone document. ------=_NextPart_000_130A_01C8AEC6.0A39D8E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The downside of this = would be that you could no longer do one pass encoding.  You would need to = compute the HMAC prior to computing the recipient infos.

 

Jim

 

 

From:= Trevor = Freeman [mailto:trevorf@exchange.microsoft.com]
Sent: Monday, May 05, 2008 2:03 PM
To: Trevor Freeman; Jim Schaad; ietf-smime@imc.org
Subject: RE: weak authentication issue with = rfc5083

 

Another suggestion is = to use the kek to wrap the hmac just like you wrapped the = CEK.

 

From:= owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 1:40 PM
To: Jim Schaad; ietf-smime@imc.org
Subject: RE: weak authentication issue with = rfc5083

 

Hi = Jim,

You can demonstrate = knowledge of both HMAC and KEK fairly simply per recipient e.g. by concatenating the = KEK with the message HMAC and hashing the result. Since Mallet does not know = the KEK they cannot compute the new hash. This fix works for both 3852 and = 5083.

 

Trevor

 

From:= Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Monday, May 05, 2008 1:23 PM
To: Trevor Freeman; ietf-smime@imc.org
Subject: RE: weak authentication issue with = rfc5083

 

Trevor,

 

The same issue also = occurs for AuthenticatedData in RFC 3852.  This has been known for a long = time.

 

I am not sure how a demonstration of the KEK would solve this issue however.  The only = way that I know to actually deal with this problem is to place the computed = MAC under encryption for each recipient.

 

Jim

 

 

From:= owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 12:52 PM
To: ietf-smime@imc.org
Subject: weak authentication issue with = rfc5083

 

We have identified a potential for spoofing when = using rfc5083.

 

Rfc5083 computes a message HMAC over the content = using the authenticated encryption algorithms. The message HMAC is calculated = based on the content and the content encryption key (CEK).

 

A number of allowed key management techniques = derive a key encryption key (KEK) which can be used to authenticate the sender e.g. Static-Static Diffie Hellman, Kerberos shared secret, shared password. = The KEK is used to encrypt the CEK per recipient.

 

However when the integrity of the message is = validated via the message HMAC, the sender only demonstrates knowledge of the CEK to = the recipient.

 

Any other recipient knows the CEK so can construct = another message using the same CEK and compute the new HMAC and reuse the = encrypted KEK data from the original message. For example:

 

Alice sends a message to Bob and Mallet. Alice uses  different = KEK’s  for both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using  = his KEK. The message decrypts and the HMAC checks out so Bob think the = message is from Alice because only Bob and Alice know the = KEK.

 =

Mallet is the recipient of the original message so he can use his KEK to learn = the message CEK. Mallet then  constructs a new message and encrypts it = using the same CEK as the original message. Mallet copies Bobs  KEK recipient = Info from Alice's message which contains the same encrypted CEK. Because = Mallet knows the CEK he can also compute the correct HMAC for the new message. = Mallet sends the new message to Bob. Bob again uses his KEK to discover the CEK = and successfully decrypts the message and the HMAC check out so Bob thinks = this new message is also from Alice.

 =

This issue only applies when there are multiple recipients. The motivation to = use the new authenticated encryption is to improve performance so solutions = like bifurcating messages to use different CEK or signing the message are counterproductive.

 

We need an additional structure to allow the sender = to demonstrate knowledge of both the KEK and CEK per recipient when sending = to multiple recipients.

What is the consensus to resolve this? =

 

We can version 5083 to document the new structure = or we can do document the new structure via a standalone document.

------=_NextPart_000_130A_01C8AEC6.0A39D8E0-- 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 m45MAYw3051378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 15:10:34 -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 m45MAYA3051377; Mon, 5 May 2008 15:10:34 -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 cx295.800onemail.com (cx295.800onemail.com [209.171.54.152]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m45MAUo6051310 for ; Mon, 5 May 2008 15:10:33 -0700 (MST) (envelope-from dbrown@certicom.com) Received: from ex13-n02.exchserver.com ([192.168.162.157]) by cx295.800onemail.com (8.13.1/8.13.1) with ESMTP id m45M9Ueo016303; Mon, 5 May 2008 18:09:31 -0400 Received: from EX40.exchserver.com ([192.168.162.205]) by ex13-n02.exchserver.com ([192.168.162.161]) with mapi; Mon, 5 May 2008 18:06:34 -0400 From: Daniel Brown To: Trevor Freeman CC: "ietf-smime@imc.org" Date: Mon, 5 May 2008 18:09:29 -0400 Subject: RE: weak authentication issue with rfc5083 Thread-Topic: weak authentication issue with rfc5083 Thread-Index: Aciu6YBkwNV9yBxhQNWEO1d1mLywFgAETq5Q Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C49217E2D694874EB820EA90DCE67619C22761EEEX40exchserverc_" MIME-Version: 1.0 X-CRXEFW-Info: Please contact Ceryx for more information X-CRXEFW-Virus: Clean X-CRXEFW-From: dbrown@certicom.com Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_000_C49217E2D694874EB820EA90DCE67619C22761EEEX40exchserverc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Trevor, Essentially the same problem was commented upon in RFC 3278: http://tools.ietf.org/html/rfc3278#section-4.1.2 but no solution was provided other than to use separate AuthenticatedData p= er recipient. There are some other possible solutions, however. For example, in the case of Diffie-Hellman, the input into the KDF used to = compute the KEK from the raw DH secret can be include the MAC tag, which pr= events message substitution. See Section 5 of http://eprint.iacr.org/2005/= 056 for more discussion. Best regards, Dan From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 3:52 PM To: ietf-smime@imc.org Subject: weak authentication issue with rfc5083 We have identified a potential for spoofing when using rfc5083. Rfc5083 computes a message HMAC over the content using the authenticated en= cryption algorithms. The message HMAC is calculated based on the content an= d the content encryption key (CEK). A number of allowed key management techniques derive a key encryption key (= KEK) which can be used to authenticate the sender e.g. Static-Static Diffie= Hellman, Kerberos shared secret, shared password. The KEK is used to encry= pt the CEK per recipient. However when the integrity of the message is validated via the message HMAC= , the sender only demonstrates knowledge of the CEK to the recipient. Any other recipient knows the CEK so can construct another message using th= e same CEK and compute the new HMAC and reuse the encrypted KEK data from t= he original message. For example: Alice sends a message to Bob and Mallet. Alice uses different KEK's for b= oth Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using his KEK.= The message decrypts and the HMAC checks out so Bob think the message is f= rom Alice because only Bob and Alice know the KEK. Mallet is the recipient of the original message so he can use his KEK to le= arn the message CEK. Mallet then constructs a new message and encrypts it = using the same CEK as the original message. Mallet copies Bobs KEK recipie= nt Info from Alice's message which contains the same encrypted CEK. Because= Mallet knows the CEK he can also compute the correct HMAC for the new mess= age. Mallet sends the new message to Bob. Bob again uses his KEK to discove= r the CEK and successfully decrypts the message and the HMAC check out so B= ob thinks this new message is also from Alice. This issue only applies when there are multiple recipients. The motivation = to use the new authenticated encryption is to improve performance so soluti= ons like bifurcating messages to use different CEK or signing the message a= re counterproductive. We need an additional structure to allow the sender to demonstrate knowledg= e of both the KEK and CEK per recipient when sending to multiple recipients= . What is the consensus to resolve this? We can version 5083 to document the new structure or we can do document the= new structure via a standalone document. --_000_C49217E2D694874EB820EA90DCE67619C22761EEEX40exchserverc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Trevor,

 =

Essentially the same pro= blem was commented upon in RFC 3278:

 =

http://tools.ietf= .org/html/rfc3278#section-4.1.2

 =

but no solution was prov= ided other than to use separate AuthenticatedData per recipient. There are some other = possible solutions, however. 

 =

For example, in the case= of Diffie-Hellman, the input into the KDF used to compute the KEK from the raw= DH secret can be include the MAC tag, which prevents message substitution.&nbs= p; See Section 5 of http://eprint.= iacr.org/2005/056 for more discussion.

 =

Best regards,=

 =

    =             Dan=

 =

From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 3:52 PM
To: ietf-smime@imc.org
Subject: weak authentication issue with rfc5083

 

We have identified a potential for spoofing when using rfc5083.

 

Rfc5083 computes a message HMAC over the content using= the authenticated encryption algorithms. The message HMAC is calculated based o= n the content and the content encryption key (CEK).

 

A number of allowed key management techniques derive a= key encryption key (KEK) which can be used to authenticate the sender e.g. Static-Static Diffie Hellman, Kerberos shared secret, shared password. The = KEK is used to encrypt the CEK per recipient.

 

However when the integrity of the message is validated= via the message HMAC, the sender only demonstrates knowledge of the CEK to the recipient.

 

Any other recipient knows the CEK so can construct ano= ther message using the same CEK and compute the new HMAC and reuse the encrypted= KEK data from the original message. For example:

 

Alice sends a message to Bob and Mallet. Alice uses  different KEK’s  for both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using  his KEK. The message decrypts and the HMAC checks out so Bob th= ink the message is from Alice because only Bob and Alice know the KEK.

 

Mallet is the recipient of the original message so he can use his KEK to learn the message CEK. Mallet then  constructs a new message and encrypts it usi= ng the same CEK as the original message. Mallet copies Bobs  KEK recipien= t Info from Alice's message which contains the same encrypted CEK. Because Ma= llet knows the CEK he can also compute the correct HMAC for the new message. Mal= let sends the new message to Bob. Bob again uses his KEK to discover the CEK an= d successfully decrypts the message and the HMAC check out so Bob thinks this= new message is also from Alice.

 

This issue only applies when there are multiple recipients. The motivation to us= e the new authenticated encryption is to improve performance so solutions lik= e bifurcating messages to use different CEK or signing the message are counterproductive.

 

We need an additional structure to allow the sender to demonstrate knowledge of both the KEK and CEK per recipient when sending to multiple recipients.

What is the consensus to resolve this?

 

We can version 5083 to document the new structure or w= e can do document the new structure via a standalone document.

--_000_C49217E2D694874EB820EA90DCE67619C22761EEEX40exchserverc_-- 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 m45LY95g035409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 14:34:09 -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 m45LY9FG035408; Mon, 5 May 2008 14:34:09 -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-05.primus.ca (mail.tor.primus.ca [216.254.136.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m45LY8B1035378; Mon, 5 May 2008 14:34:08 -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-05.primus.ca with esmtps (TLSv1:RC4-MD5:128) (Exim 4.63) (envelope-from ) id 1Jt8Io-0007mq-2E; Mon, 05 May 2008 17:32:55 -0400 From: "Tony Capel" To: "'Turner, Sean P.'" , "'Paul Hoffman'" , Subject: RE: S/MIME v3.2 IDs key size text Date: Mon, 5 May 2008 17:34:02 -0400 Message-ID: <004301c8aef7$bcafeba0$02b5a8c0@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: <023701c8aef2$ad31a650$0201a8c0@Wylie> Importance: Normal Thread-Index: AcitjLJkvgon3zgMT46W137Z98cRiQBUq31QAASyTyAAAQJGwA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sean: Agreed, the text in 3850bis and 3851bis needs to align. I have no = problems with support for smaller key sizes. I expect constraints on key size to be implemented by the certificate = issuer anyway. If you get a 512 key in a cert you trust you must be able to = use it, no? =20 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: May 5, 2008 4:58 PM | To: 'Tony Capel'; 'Paul Hoffman'; ietf-smime@imc.org | Subject: RE: S/MIME v3.2 IDs key size text |=20 |=20 |=20 | Tony, |=20 | There was a comment from Paul against the text you cite from=20 | 3850bis. He objected to moving the lower bounds from 512 to=20 | 1024. I figured I'd post both -02 drafts once we knocked this=20 | issue out. |=20 | spt |=20 | >-----Original Message----- | >From: Tony Capel [mailto:capel@comgate.com] | >Sent: Monday, May 05, 2008 4:09 PM | >To: 'Paul Hoffman'; 'Turner, Sean P.'; ietf-smime@imc.org | >Subject: RE: S/MIME v3.2 IDs key size text | > | >All: | > | >I agree that deleting " namely 1024 bits" from the first | >sentence of the proposed security considerations section=20 | >paragraph is good. The second "1024" | >in the proposed paragraph is not a problem for me since it is=20 | >not "normative". | > | >With respect to section 4.1 (Key Pair Generation). Is it | >intended to change the title of this section? The second=20 | >paragraph of the current text in 3851bis-01.txt begins "If an=20 | >S/MIME agent needs to generate ...". So if the S/MIME agent=20 | >does NOT need to generate keys (and this is typically the=20 | >case, most enrollment & key generation are done externally to=20 | >messaging clients) the balance of this paragraph (which=20 | >mentions the key sizes) is not normative (as currently drafted=20 | >- its quite possible that the last sentence of this paragraph=20 | >should have been in a separate paragraph). Key generation=20 | >requirements are normally (hopefully!) cited in the=20 | >corresponding CP, where things such as required key sizes,=20 | >where they are generated (locally or at the CA), FIPS-140=20 | >Level, etc. should be (!!) explicitly identified. Maybe the=20 | >second paragraph of | >4.1 could be replaced with a simple statement: | > | >"If an S/MIME agent needs to generate one or more key pairs, | >each SHOULD be generated according to the corresponding=20 | >certificate policy, refer for example to [RFC3647]." | > | >The proposed text, and the discussion so far, is really | >speaking about "what range of RSA key sizes" needs to be=20 | >supported. We are NOT providing security advice, we are just=20 | >trying to ensure that most smime v3.2 implementations will=20 | >interwork in the typical environments expected "in the wild"=20 | >(and special environments will be understood by purchasers=20 | >anyway, so we likely need not worry about high security=20 | >applications - only the general "public" | >environments).=20 | > | >A similar issue is already addressed in CERT v3.2 ( | >draft-ietf-smime-3850bis-01.txt ) in Section 4.3 for=20 | >certificate validation. | >We might consider copying the last sentence of CERT v3.2 Sec=20 | >4.3 to the end of sections 2.2 and 2.3 (just before the Notes): | > | > "Key sizes from 1024 bits to 2048 bits MUST be supported." | > | >This would also have the advantage of aligning CERT and MSG. | > | >Tony | > | > | >| -----Original Message----- | >| From: owner-ietf-smime@mail.imc.org=20 | >| [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Paul Hoffman | >| Sent: May 3, 2008 10:08 PM | >| To: Turner, Sean P.; ietf-smime@imc.org | >| Subject: RE: S/MIME v3.2 IDs key size text | >|=20 | >|=20 | >|=20 | >| At 8:51 PM -0400 5/3/08, Turner, Sean P. wrote: | >| >I think if we struck ", namely 1024 bits" from the text in | >| the security | >| >considerations that it's still a true statement and we | >won't have to | >| >change it every time we update the spec. | >|=20 | >| I'm OK with that, but I also feel that if we're updating=20 | the minimum | >| mandatory signing length, it is trivial to update the Security=20 | >| Considerations as well. | >|=20 | > |=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 m45L3YQ9023146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 14:03:34 -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 m45L3YgZ023144; Mon, 5 May 2008 14:03:34 -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.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m45L3V00023118 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Mon, 5 May 2008 14:03:33 -0700 (MST) (envelope-from trevorf@exchange.microsoft.com) Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) by DF-GWY-07.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 5 May 2008 14:04:10 -0700 Received: from df-mlt-02.exchange.corp.microsoft.com (157.54.94.20) by df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 5 May 2008 14:04:10 -0700 Received: from DF-MBX-61.exchange.corp.microsoft.com ([169.254.2.227]) by DF-MLT-02.exchange.corp.microsoft.com ([157.54.94.20]) with mapi; Mon, 5 May 2008 14:04:02 -0700 From: Trevor Freeman To: Trevor Freeman , Jim Schaad , "ietf-smime@imc.org" Date: Mon, 5 May 2008 21:03:23 +0000 Subject: RE: weak authentication issue with rfc5083 Thread-Topic: weak authentication issue with rfc5083 Thread-Index: Aciu6YBkwNV9yBxhQNWEO1d1mLywFgABCUHgAAAYJfAAAU9AUA== Message-ID: References: <12c801c8aeed$ddd47670$997d6350$@com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_F767238E699C2E43895DDFB5F435088F0C2C06CFE4DFMBX61exchan_" MIME-Version: 1.0 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_000_F767238E699C2E43895DDFB5F435088F0C2C06CFE4DFMBX61exchan_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Another suggestion is to use the kek to wrap the hmac just like you wrapped= the CEK. From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 1:40 PM To: Jim Schaad; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Hi Jim, You can demonstrate knowledge of both HMAC and KEK fairly simply per recipi= ent e.g. by concatenating the KEK with the message HMAC and hashing the res= ult. Since Mallet does not know the KEK they cannot compute the new hash. T= his fix works for both 3852 and 5083. Trevor From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, May 05, 2008 1:23 PM To: Trevor Freeman; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Trevor, The same issue also occurs for AuthenticatedData in RFC 3852. This has bee= n known for a long time. I am not sure how a demonstration of the KEK would solve this issue however= . The only way that I know to actually deal with this problem is to place = the computed MAC under encryption for each recipient. Jim From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 12:52 PM To: ietf-smime@imc.org Subject: weak authentication issue with rfc5083 We have identified a potential for spoofing when using rfc5083. Rfc5083 computes a message HMAC over the content using the authenticated en= cryption algorithms. The message HMAC is calculated based on the content an= d the content encryption key (CEK). A number of allowed key management techniques derive a key encryption key (= KEK) which can be used to authenticate the sender e.g. Static-Static Diffie= Hellman, Kerberos shared secret, shared password. The KEK is used to encry= pt the CEK per recipient. However when the integrity of the message is validated via the message HMAC= , the sender only demonstrates knowledge of the CEK to the recipient. Any other recipient knows the CEK so can construct another message using th= e same CEK and compute the new HMAC and reuse the encrypted KEK data from t= he original message. For example: Alice sends a message to Bob and Mallet. Alice uses different KEK's for b= oth Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using his KEK.= The message decrypts and the HMAC checks out so Bob think the message is f= rom Alice because only Bob and Alice know the KEK. Mallet is the recipient of the original message so he can use his KEK to le= arn the message CEK. Mallet then constructs a new message and encrypts it = using the same CEK as the original message. Mallet copies Bobs KEK recipie= nt Info from Alice's message which contains the same encrypted CEK. Because= Mallet knows the CEK he can also compute the correct HMAC for the new mess= age. Mallet sends the new message to Bob. Bob again uses his KEK to discove= r the CEK and successfully decrypts the message and the HMAC check out so B= ob thinks this new message is also from Alice. This issue only applies when there are multiple recipients. The motivation = to use the new authenticated encryption is to improve performance so soluti= ons like bifurcating messages to use different CEK or signing the message a= re counterproductive. We need an additional structure to allow the sender to demonstrate knowledg= e of both the KEK and CEK per recipient when sending to multiple recipients= . What is the consensus to resolve this? We can version 5083 to document the new structure or we can do document the= new structure via a standalone document. --_000_F767238E699C2E43895DDFB5F435088F0C2C06CFE4DFMBX61exchan_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Another suggestion is to= use the kek to wrap the hmac just like you wrapped the CEK.

 =

From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 1:40 PM
To: Jim Schaad; ietf-smime@imc.org
Subject: RE: weak authentication issue with rfc5083

 

Hi Jim,

You can demonstrate know= ledge of both HMAC and KEK fairly simply per recipient e.g. by concatenating the KEK with the message HMAC and hashing the result. Since Mallet does not know th= e KEK they cannot compute the new hash. This fix works for both 3852 and 5083= .

 =

Trevor=

 =

From: Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Monday, May 05, 2008 1:23 PM
To: Trevor Freeman; ietf-smime@imc.org
Subject: RE: weak authentication issue with rfc5083

 

Trevor,

 =

The same issue also occu= rs for AuthenticatedData in RFC 3852.  This has been known for a long time.

 =

I am not sure how a demonstration of the KEK would solve this issue however.  The only way that I know to actually deal with this problem is to place the computed MAC under encryption for each recipient.

 =

Jim

 =

 =

From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 12:52 PM
To: ietf-smime@imc.org
Subject: weak authentication issue with rfc5083

 

We have identified a potential for spoofing when using rfc5083.

 

Rfc5083 computes a message HMAC over the content using= the authenticated encryption algorithms. The message HMAC is calculated based o= n the content and the content encryption key (CEK).

 

A number of allowed key management techniques derive a= key encryption key (KEK) which can be used to authenticate the sender e.g. Static-Static Diffie Hellman, Kerberos shared secret, shared password. The = KEK is used to encrypt the CEK per recipient.

 

However when the integrity of the message is validated= via the message HMAC, the sender only demonstrates knowledge of the CEK to the recipient.

 

Any other recipient knows the CEK so can construct ano= ther message using the same CEK and compute the new HMAC and reuse the encrypted= KEK data from the original message. For example:

 

Alice sends a message to Bob and Mallet. Alice uses  different KEK’s  for both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using  his KEK. The message decrypts and the HMAC checks out so Bob th= ink the message is from Alice because only Bob and Alice know the KEK.

 

Mallet is the recipient of the original message so he can use his KEK to learn the message CEK. Mallet then  constructs a new message and encrypts it usi= ng the same CEK as the original message. Mallet copies Bobs  KEK recipien= t Info from Alice's message which contains the same encrypted CEK. Because Ma= llet knows the CEK he can also compute the correct HMAC for the new message. Mal= let sends the new message to Bob. Bob again uses his KEK to discover the CEK an= d successfully decrypts the message and the HMAC check out so Bob thinks this= new message is also from Alice.

 

This issue only applies when there are multiple recipients. The motivation to us= e the new authenticated encryption is to improve performance so solutions lik= e bifurcating messages to use different CEK or signing the message are counterproductive.

 

We need an additional structure to allow the sender to demonstrate knowledge of both the KEK and CEK per recipient when sending to multiple recipients.

What is the consensus to resolve this?

 

We can version 5083 to document the new structure or w= e can do document the new structure via a standalone document.

--_000_F767238E699C2E43895DDFB5F435088F0C2C06CFE4DFMBX61exchan_-- 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 m45L22rv022398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 14:02:02 -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 m45L22fX022397; Mon, 5 May 2008 14:02:02 -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 smtp102.biz.mail.re2.yahoo.com (smtp102.biz.mail.re2.yahoo.com [68.142.229.216]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m45L20gA022369 for ; Mon, 5 May 2008 14:02:01 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 24369 invoked from network); 5 May 2008 21:01:51 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.241.4.90 with login) by smtp102.biz.mail.re2.yahoo.com with SMTP; 5 May 2008 21:01:51 -0000 X-YMail-OSG: XKczkFEVM1la1gVI12AR2K8h_abcE9lTgciwaZ6cPOQxTAnV23q.7HIVQ6cCrs_IXocsbO9ykCuVu.QXMmlNVEJiYHRG0vk30oorwW3M._txI3Aw9zmXA21IDxhDbw_7lDA- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "'Tony Capel'" , "'Paul Hoffman'" , References: <003401c8aeeb$ccf3daa0$02b5a8c0@tony> Subject: RE: S/MIME v3.2 IDs key size text Date: Mon, 5 May 2008 16:57:48 -0400 Organization: IECA, Inc. Message-ID: <023701c8aef2$ad31a650$0201a8c0@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.3198 Thread-Index: AcitjLJkvgon3zgMT46W137Z98cRiQBUq31QAASyTyA= In-Reply-To: <003401c8aeeb$ccf3daa0$02b5a8c0@tony> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tony, There was a comment from Paul against the text you cite from 3850bis. He objected to moving the lower bounds from 512 to 1024. I figured I'd post both -02 drafts once we knocked this issue out. spt >-----Original Message----- >From: Tony Capel [mailto:capel@comgate.com] >Sent: Monday, May 05, 2008 4:09 PM >To: 'Paul Hoffman'; 'Turner, Sean P.'; ietf-smime@imc.org >Subject: RE: S/MIME v3.2 IDs key size text > >All: > >I agree that deleting " namely 1024 bits" from the first >sentence of the proposed security considerations section >paragraph is good. The second "1024" >in the proposed paragraph is not a problem for me since it is >not "normative". > >With respect to section 4.1 (Key Pair Generation). Is it >intended to change the title of this section? The second >paragraph of the current text in 3851bis-01.txt begins "If an >S/MIME agent needs to generate ...". So if the S/MIME agent >does NOT need to generate keys (and this is typically the >case, most enrollment & key generation are done externally to >messaging clients) the balance of this paragraph (which >mentions the key sizes) is not normative (as currently drafted >- its quite possible that the last sentence of this paragraph >should have been in a separate paragraph). Key generation >requirements are normally (hopefully!) cited in the >corresponding CP, where things such as required key sizes, >where they are generated (locally or at the CA), FIPS-140 >Level, etc. should be (!!) explicitly identified. Maybe the >second paragraph of >4.1 could be replaced with a simple statement: > >"If an S/MIME agent needs to generate one or more key pairs, >each SHOULD be generated according to the corresponding >certificate policy, refer for example to [RFC3647]." > >The proposed text, and the discussion so far, is really >speaking about "what range of RSA key sizes" needs to be >supported. We are NOT providing security advice, we are just >trying to ensure that most smime v3.2 implementations will >interwork in the typical environments expected "in the wild" >(and special environments will be understood by purchasers >anyway, so we likely need not worry about high security >applications - only the general "public" >environments). > >A similar issue is already addressed in CERT v3.2 ( >draft-ietf-smime-3850bis-01.txt ) in Section 4.3 for >certificate validation. >We might consider copying the last sentence of CERT v3.2 Sec >4.3 to the end of sections 2.2 and 2.3 (just before the Notes): > > "Key sizes from 1024 bits to 2048 bits MUST be supported." > >This would also have the advantage of aligning CERT and MSG. > >Tony > > >| -----Original Message----- >| From: owner-ietf-smime@mail.imc.org >| [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Paul Hoffman >| Sent: May 3, 2008 10:08 PM >| To: Turner, Sean P.; ietf-smime@imc.org >| Subject: RE: S/MIME v3.2 IDs key size text >| >| >| >| At 8:51 PM -0400 5/3/08, Turner, Sean P. wrote: >| >I think if we struck ", namely 1024 bits" from the text in >| the security >| >considerations that it's still a true statement and we >won't have to >| >change it every time we update the spec. >| >| I'm OK with that, but I also feel that if we're updating the minimum >| mandatory signing length, it is trivial to update the Security >| Considerations as well. >| > 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 m45Kep54014686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 13:40: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 m45KepPr014685; Mon, 5 May 2008 13:40: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 mail.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.1.17]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m45Ken5B014676 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Mon, 5 May 2008 13:40:50 -0700 (MST) (envelope-from trevorf@exchange.microsoft.com) Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) by DF-GWY-05.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 5 May 2008 13:41:22 -0700 Received: from df-mlt-02.exchange.corp.microsoft.com (157.54.94.20) by df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 5 May 2008 13:41:22 -0700 Received: from DF-MBX-61.exchange.corp.microsoft.com ([169.254.2.227]) by DF-MLT-02.exchange.corp.microsoft.com ([157.54.94.20]) with mapi; Mon, 5 May 2008 13:40:58 -0700 From: Trevor Freeman To: Jim Schaad , "ietf-smime@imc.org" Date: Mon, 5 May 2008 20:40:19 +0000 Subject: RE: weak authentication issue with rfc5083 Thread-Topic: weak authentication issue with rfc5083 Thread-Index: Aciu6YBkwNV9yBxhQNWEO1d1mLywFgABCUHgAAAYJfA= Message-ID: References: <12c801c8aeed$ddd47670$997d6350$@com> In-Reply-To: <12c801c8aeed$ddd47670$997d6350$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_F767238E699C2E43895DDFB5F435088F0C2C06B884DFMBX61exchan_" MIME-Version: 1.0 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_000_F767238E699C2E43895DDFB5F435088F0C2C06B884DFMBX61exchan_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, You can demonstrate knowledge of both HMAC and KEK fairly simply per recipi= ent e.g. by concatenating the KEK with the message HMAC and hashing the res= ult. Since Mallet does not know the KEK they cannot compute the new hash. T= his fix works for both 3852 and 5083. Trevor From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, May 05, 2008 1:23 PM To: Trevor Freeman; ietf-smime@imc.org Subject: RE: weak authentication issue with rfc5083 Trevor, The same issue also occurs for AuthenticatedData in RFC 3852. This has bee= n known for a long time. I am not sure how a demonstration of the KEK would solve this issue however= . The only way that I know to actually deal with this problem is to place = the computed MAC under encryption for each recipient. Jim From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 12:52 PM To: ietf-smime@imc.org Subject: weak authentication issue with rfc5083 We have identified a potential for spoofing when using rfc5083. Rfc5083 computes a message HMAC over the content using the authenticated en= cryption algorithms. The message HMAC is calculated based on the content an= d the content encryption key (CEK). A number of allowed key management techniques derive a key encryption key (= KEK) which can be used to authenticate the sender e.g. Static-Static Diffie= Hellman, Kerberos shared secret, shared password. The KEK is used to encry= pt the CEK per recipient. However when the integrity of the message is validated via the message HMAC= , the sender only demonstrates knowledge of the CEK to the recipient. Any other recipient knows the CEK so can construct another message using th= e same CEK and compute the new HMAC and reuse the encrypted KEK data from t= he original message. For example: Alice sends a message to Bob and Mallet. Alice uses different KEK's for b= oth Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using his KEK.= The message decrypts and the HMAC checks out so Bob think the message is f= rom Alice because only Bob and Alice know the KEK. Mallet is the recipient of the original message so he can use his KEK to le= arn the message CEK. Mallet then constructs a new message and encrypts it = using the same CEK as the original message. Mallet copies Bobs KEK recipie= nt Info from Alice's message which contains the same encrypted CEK. Because= Mallet knows the CEK he can also compute the correct HMAC for the new mess= age. Mallet sends the new message to Bob. Bob again uses his KEK to discove= r the CEK and successfully decrypts the message and the HMAC check out so B= ob thinks this new message is also from Alice. This issue only applies when there are multiple recipients. The motivation = to use the new authenticated encryption is to improve performance so soluti= ons like bifurcating messages to use different CEK or signing the message a= re counterproductive. We need an additional structure to allow the sender to demonstrate knowledg= e of both the KEK and CEK per recipient when sending to multiple recipients= . What is the consensus to resolve this? We can version 5083 to document the new structure or we can do document the= new structure via a standalone document. --_000_F767238E699C2E43895DDFB5F435088F0C2C06B884DFMBX61exchan_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim,

You can demonstrate know= ledge of both HMAC and KEK fairly simply per recipient e.g. by concatenating the KEK with the message HMAC and hashing the result. Since Mallet does not know th= e KEK they cannot compute the new hash. This fix works for both 3852 and 5083.

 =

Trevor=

 =

From: Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Monday, May 05, 2008 1:23 PM
To: Trevor Freeman; ietf-smime@imc.org
Subject: RE: weak authentication issue with rfc5083

 

Trevor,

 =

The same issue also occu= rs for AuthenticatedData in RFC 3852.  This has been known for a long time.

 =

I am not sure how a demonstration of the KEK would solve this issue however.  The only way that I know to actually deal with this problem is to place the computed MAC under encryption for each recipient.

 =

Jim

 =

 =

From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 12:52 PM
To: ietf-smime@imc.org
Subject: weak authentication issue with rfc5083

 

We have identified a potential for spoofing when using rfc5083.

 

Rfc5083 computes a message HMAC over the content using= the authenticated encryption algorithms. The message HMAC is calculated based on the content = and the content encryption key (CEK).

 

A number of allowed key management techniques derive a= key encryption key (KEK) which can be used to authenticate the sender e.g. Static-Static Diffie Hellman, Kerberos shared secret, shared password. The = KEK is used to encrypt the CEK per recipient.

 

However when the integrity of the message is validated= via the message HMAC, the sender only demonstrates knowledge of the CEK to the recipient.

 

Any other recipient knows the CEK so can construct ano= ther message using the same CEK and compute the new HMAC and reuse the encrypted= KEK data from the original message. For example:

 

Alice sends a message to Bob and Mallet. Alice uses  different KEK’s  for both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using  his KEK. The message decrypts and the HMAC checks out so Bob th= ink the message is from Alice because only Bob and Alice know the KEK.

 

Mallet is the recipient of the original message so he can use his KEK to learn the message CEK. Mallet then  constructs a new message and encrypts it usi= ng the same CEK as the original message. Mallet copies Bobs  KEK recipien= t Info from Alice's message which contains the same encrypted CEK. Because Ma= llet knows the CEK he can also compute the correct HMAC for the new message. Mal= let sends the new message to Bob. Bob again uses his KEK to discover the CEK an= d successfully decrypts the message and the HMAC check out so Bob thinks this= new message is also from Alice.

 

This issue only applies when there are multiple recipients. The motivation to us= e the new authenticated encryption is to improve performance so solutions lik= e bifurcating messages to use different CEK or signing the message are counterproductive.

 

We need an additional structure to allow the sender to demonstrate knowledge of both the KEK and CEK per recipient when sending to multiple recipients.

What is the consensus to resolve this?

 

We can version 5083 to document the new structure or w= e can do document the new structure via a standalone document.

--_000_F767238E699C2E43895DDFB5F435088F0C2C06B884DFMBX61exchan_-- 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 m45KNRLh008142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 13:23:27 -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 m45KNRjP008141; Mon, 5 May 2008 13:23:27 -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 smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m45KNOeW008120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 5 May 2008 13:23:25 -0700 (MST) (envelope-from ietf@augustcellars.com) Received: from GALATIONS (unknown [207.202.179.27]) by smtp3.pacifier.net (Postfix) with ESMTP id F3F6A8D35; Mon, 5 May 2008 13:23:22 -0700 (PDT) From: "Jim Schaad" To: "'Trevor Freeman'" , References: In-Reply-To: Subject: RE: weak authentication issue with rfc5083 Date: Mon, 5 May 2008 13:23:22 -0700 Message-ID: <12c801c8aeed$ddd47670$997d6350$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_12C9_01C8AEB3.31759E70" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aciu6YBkwNV9yBxhQNWEO1d1mLywFgABCUHg Content-Language: en-us Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. ------=_NextPart_000_12C9_01C8AEB3.31759E70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Trevor, The same issue also occurs for AuthenticatedData in RFC 3852. This has been known for a long time. I am not sure how a demonstration of the KEK would solve this issue however. The only way that I know to actually deal with this problem is to place the computed MAC under encryption for each recipient. Jim From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor Freeman Sent: Monday, May 05, 2008 12:52 PM To: ietf-smime@imc.org Subject: weak authentication issue with rfc5083 We have identified a potential for spoofing when using rfc5083. Rfc5083 computes a message HMAC over the content using the authenticated encryption algorithms. The message HMAC is calculated based on the content and the content encryption key (CEK). A number of allowed key management techniques derive a key encryption key (KEK) which can be used to authenticate the sender e.g. Static-Static Diffie Hellman, Kerberos shared secret, shared password. The KEK is used to encrypt the CEK per recipient. However when the integrity of the message is validated via the message HMAC, the sender only demonstrates knowledge of the CEK to the recipient. Any other recipient knows the CEK so can construct another message using the same CEK and compute the new HMAC and reuse the encrypted KEK data from the original message. For example: Alice sends a message to Bob and Mallet. Alice uses different KEK's for both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using his KEK. The message decrypts and the HMAC checks out so Bob think the message is from Alice because only Bob and Alice know the KEK. Mallet is the recipient of the original message so he can use his KEK to learn the message CEK. Mallet then constructs a new message and encrypts it using the same CEK as the original message. Mallet copies Bobs KEK recipient Info from Alice's message which contains the same encrypted CEK. Because Mallet knows the CEK he can also compute the correct HMAC for the new message. Mallet sends the new message to Bob. Bob again uses his KEK to discover the CEK and successfully decrypts the message and the HMAC check out so Bob thinks this new message is also from Alice. This issue only applies when there are multiple recipients. The motivation to use the new authenticated encryption is to improve performance so solutions like bifurcating messages to use different CEK or signing the message are counterproductive. We need an additional structure to allow the sender to demonstrate knowledge of both the KEK and CEK per recipient when sending to multiple recipients. What is the consensus to resolve this? We can version 5083 to document the new structure or we can do document the new structure via a standalone document. ------=_NextPart_000_12C9_01C8AEB3.31759E70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Trevor,

 

The same issue also = occurs for AuthenticatedData in RFC 3852.  This has been known for a long = time.

 

I am not sure how a demonstration of the KEK would solve this issue however.  The only = way that I know to actually deal with this problem is to place the computed MAC = under encryption for each recipient.

 

Jim

 

 

From:= = owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Trevor = Freeman
Sent: Monday, May 05, 2008 12:52 PM
To: ietf-smime@imc.org
Subject: weak authentication issue with = rfc5083

 

We have identified a potential for spoofing when = using rfc5083.

 

Rfc5083 computes a message HMAC over the content = using the authenticated encryption algorithms. The message HMAC is calculated = based on the content and the content encryption key (CEK).

 

A number of allowed key management techniques = derive a key encryption key (KEK) which can be used to authenticate the sender e.g. Static-Static Diffie Hellman, Kerberos shared secret, shared password. = The KEK is used to encrypt the CEK per recipient.

 

However when the integrity of the message is = validated via the message HMAC, the sender only demonstrates knowledge of the CEK to = the recipient.

 

Any other recipient knows the CEK so can construct = another message using the same CEK and compute the new HMAC and reuse the = encrypted KEK data from the original message. For example:

 

Alice sends a message to Bob and Mallet. Alice uses  different = KEK’s  for both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using  = his KEK. The message decrypts and the HMAC checks out so Bob think the = message is from Alice because only Bob and Alice know the = KEK.

 =

Mallet is the recipient of the original message so he can use his KEK to learn = the message CEK. Mallet then  constructs a new message and encrypts it = using the same CEK as the original message. Mallet copies Bobs  KEK = recipient Info from Alice's message which contains the same encrypted CEK. Because = Mallet knows the CEK he can also compute the correct HMAC for the new message. = Mallet sends the new message to Bob. Bob again uses his KEK to discover the CEK = and successfully decrypts the message and the HMAC check out so Bob thinks = this new message is also from Alice.

 =

This issue only applies when there are multiple recipients. The motivation to = use the new authenticated encryption is to improve performance so solutions = like bifurcating messages to use different CEK or signing the message are counterproductive.

 

We need an additional structure to allow the sender = to demonstrate knowledge of both the KEK and CEK per recipient when sending = to multiple recipients.

What is the consensus to resolve this? =

 

We can version 5083 to document the new structure = or we can do document the new structure via a standalone document.

------=_NextPart_000_12C9_01C8AEB3.31759E70-- 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 m45K8g97001999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 13:08:42 -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 m45K8g5m001998; Mon, 5 May 2008 13:08:42 -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 (mail.tor.primus.ca [216.254.136.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m45K8fn9001974; Mon, 5 May 2008 13:08:42 -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 1Jt6zI-0004PL-20; Mon, 05 May 2008 16:08:40 -0400 From: "Tony Capel" To: "'Paul Hoffman'" , "'Turner, Sean P.'" , Subject: RE: S/MIME v3.2 IDs key size text Date: Mon, 5 May 2008 16:08:35 -0400 Message-ID: <003401c8aeeb$ccf3daa0$02b5a8c0@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: AcitjLJkvgon3zgMT46W137Z98cRiQBUq31Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All: I agree that deleting " namely 1024 bits" from the first sentence of the proposed security considerations section paragraph is good. The second = "1024" in the proposed paragraph is not a problem for me since it is not = "normative". With respect to section 4.1 (Key Pair Generation). Is it intended to = change the title of this section? The second paragraph of the current text in 3851bis-01.txt begins "If an S/MIME agent needs to generate ...". So if = the S/MIME agent does NOT need to generate keys (and this is typically the = case, most enrollment & key generation are done externally to messaging = clients) the balance of this paragraph (which mentions the key sizes) is not = normative (as currently drafted - its quite possible that the last sentence of this = paragraph should have been in a separate paragraph). Key generation requirements = are normally (hopefully!) cited in the corresponding CP, where things such = as required key sizes, where they are generated (locally or at the CA), = FIPS-140 Level, etc. should be (!!) explicitly identified. Maybe the second = paragraph of 4.1 could be replaced with a simple statement: "If an S/MIME agent needs to generate one or more key pairs, each SHOULD = be generated according to the corresponding certificate policy, refer for = example to [RFC3647]." The proposed text, and the discussion so far, is really speaking about = "what range of RSA key sizes" needs to be supported. We are NOT providing = security advice, we are just trying to ensure that most smime v3.2 = implementations will interwork in the typical environments expected "in the wild" (and = special environments will be understood by purchasers anyway, so we likely need = not worry about high security applications - only the general "public" environments).=20 A similar issue is already addressed in CERT v3.2 ( draft-ietf-smime-3850bis-01.txt ) in Section 4.3 for certificate = validation. We might consider copying the last sentence of CERT v3.2 Sec 4.3 to the = end of sections 2.2 and 2.3 (just before the Notes): "Key sizes from 1024 bits to 2048 bits MUST be supported."=20 This would also have the advantage of aligning CERT and MSG. Tony | -----Original Message----- | From: owner-ietf-smime@mail.imc.org=20 | [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Paul Hoffman | Sent: May 3, 2008 10:08 PM | To: Turner, Sean P.; ietf-smime@imc.org | Subject: RE: S/MIME v3.2 IDs key size text |=20 |=20 |=20 | At 8:51 PM -0400 5/3/08, Turner, Sean P. wrote: | >I think if we struck ", namely 1024 bits" from the text in=20 | the security=20 | >considerations that it's still a true statement and we won't have to=20 | >change it every time we update the spec. |=20 | I'm OK with that, but I also feel that if we're updating the minimum=20 | mandatory signing length, it is trivial to update the Security=20 | Considerations as well. |=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 m45JqCnq095467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 12:52: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 m45JqCew095466; Mon, 5 May 2008 12:52: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.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m45JqBYD095460 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Mon, 5 May 2008 12:52:11 -0700 (MST) (envelope-from trevorf@exchange.microsoft.com) Received: from df-bhd-01.exchange.corp.microsoft.com (157.54.111.57) by DF-GWY-07.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 5 May 2008 12:52:49 -0700 Received: from df-mlt-02.exchange.corp.microsoft.com (157.54.94.20) by df-bhd-01.exchange.corp.microsoft.com (157.54.111.57) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 5 May 2008 12:52:49 -0700 Received: from DF-MBX-61.exchange.corp.microsoft.com ([169.254.2.227]) by DF-MLT-02.exchange.corp.microsoft.com ([157.54.94.20]) with mapi; Mon, 5 May 2008 12:52:47 -0700 From: Trevor Freeman To: "ietf-smime@imc.org" Date: Mon, 5 May 2008 19:52:08 +0000 Subject: weak authentication issue with rfc5083 Thread-Topic: weak authentication issue with rfc5083 Thread-Index: Aciu6YBkwNV9yBxhQNWEO1d1mLywFg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_F767238E699C2E43895DDFB5F435088F0C2C06204ADFMBX61exchan_" MIME-Version: 1.0 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_000_F767238E699C2E43895DDFB5F435088F0C2C06204ADFMBX61exchan_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have identified a potential for spoofing when using rfc5083. Rfc5083 computes a message HMAC over the content using the authenticated en= cryption algorithms. The message HMAC is calculated based on the content an= d the content encryption key (CEK). A number of allowed key management techniques derive a key encryption key (= KEK) which can be used to authenticate the sender e.g. Static-Static Diffie= Hellman, Kerberos shared secret, shared password. The KEK is used to encry= pt the CEK per recipient. However when the integrity of the message is validated via the message HMAC= , the sender only demonstrates knowledge of the CEK to the recipient. Any other recipient knows the CEK so can construct another message using th= e same CEK and compute the new HMAC and reuse the encrypted KEK data from t= he original message. For example: Alice sends a message to Bob and Mallet. Alice uses different KEK's for b= oth Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using his KEK.= The message decrypts and the HMAC checks out so Bob think the message is f= rom Alice because only Bob and Alice know the KEK. Mallet is the recipient of the original message so he can use his KEK to le= arn the message CEK. Mallet then constructs a new message and encrypts it = using the same CEK as the original message. Mallet copies Bobs KEK recipie= nt Info from Alice's message which contains the same encrypted CEK. Because= Mallet knows the CEK he can also compute the correct HMAC for the new mess= age. Mallet sends the new message to Bob. Bob again uses his KEK to discove= r the CEK and successfully decrypts the message and the HMAC check out so B= ob thinks this new message is also from Alice. This issue only applies when there are multiple recipients. The motivation = to use the new authenticated encryption is to improve performance so soluti= ons like bifurcating messages to use different CEK or signing the message a= re counterproductive. We need an additional structure to allow the sender to demonstrate knowledg= e of both the KEK and CEK per recipient when sending to multiple recipients= . What is the consensus to resolve this? We can version 5083 to document the new structure or we can do document the= new structure via a standalone document. --_000_F767238E699C2E43895DDFB5F435088F0C2C06204ADFMBX61exchan_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have identified a potential for spoofing when using rfc5083.

 

Rfc5083 computes a message HMAC over the content using= the authenticated encryption algorithms. The message HMAC is calculated based on the content = and the content encryption key (CEK).

 

A number of allowed key management techniques derive a= key encryption key (KEK) which can be used to authenticate the sender e.g. Static-Static Diffie Hellman, Kerberos shared secret, shared password. The KEK is used to= encrypt the CEK per recipient.

 

However when the integrity of the message is validated= via the message HMAC, the sender only demonstrates knowledge of the CEK to the recipient.

 

Any other recipient knows the CEK so can construct ano= ther message using the same CEK and compute the new HMAC and reuse the encrypted KEK dat= a from the original message. For example:

 

Alice sends a message to Bob and Mallet. Alice uses  different KEK’s &= nbsp;for both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using  hi= s KEK. The message decrypts and the HMAC checks out so Bob think the message is fr= om Alice because only Bob and Alice know the KEK.

 

Mallet is the recipient of the original message so he can use his KEK to learn the message CEK. Mallet then  constructs a new message and encrypts it usi= ng the same CEK as the original message. Mallet copies Bobs  KEK recipien= t Info from Alice's message which contains the same encrypted CEK. Because Ma= llet knows the CEK he can also compute the correct HMAC for the new message. Mal= let sends the new message to Bob. Bob again uses his KEK to discover the CEK an= d successfully decrypts the message and the HMAC check out so Bob thinks this= new message is also from Alice.

 

This issue only applies when there are multiple recipients. The motivation to us= e the new authenticated encryption is to improve performance so solutions like bi= furcating messages to use different CEK or signing the message are counterproductive.=

 

We need an additional structure to allow the sender to= demonstrate knowledge of both the KEK and CEK per recipient when sending to multiple re= cipients.

What is the consensus to resolve this?

 

We can version 5083 to document the new structure or w= e can do document the new structure via a standalone document.

--_000_F767238E699C2E43895DDFB5F435088F0C2C06204ADFMBX61exchan_-- 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 m44InWtP088243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 May 2008 11:49: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 m44InWeB088242; Sun, 4 May 2008 11:49: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 mail.voltage.com (mail.voltage.com [209.213.222.98]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m44InVVs088218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 May 2008 11:49:31 -0700 (MST) (envelope-from martin@voltage.com) Received: from hqmailsvr01.voltage.com (hqmailsvr01.voltage.com [172.16.0.22]) by mail.voltage.com (8.13.7/8.13.7) with ESMTP id m44InpPh000381 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 4 May 2008 11:49:51 -0700 Received: from hqmailsvr01.voltage.com ([172.16.0.22]) by hqmailsvr01.voltage.com ([172.16.0.22]) with mapi; Sun, 4 May 2008 11:49:30 -0700 From: Luther Martin To: "'Paul Hoffman'" , "ietf-smime@imc.org" Date: Sun, 4 May 2008 11:49:29 -0700 Subject: RE: S/MIME v3.2 IDs key size text (resend, this time not opaque signed with 2k key) Thread-Topic: S/MIME v3.2 IDs key size text (resend, this time not opaque signed with 2k key) Thread-Index: AcitVuoIcgNfTmIRSx+nHgGspK6qxAAvqQKw Message-ID: References: <001801c8ad4e$7c0bc6a0$02b5a8c0@tony> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=4.65.7161:2.4.4,1.2.40,4.0.164 definitions=2008-05-04_05:2008-05-02,2008-05-04,2008-05-04 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=3.1.0-0804140000 definitions=main-0805040108 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: Saturday, May 03, 2008 12:11 PM > To: ietf-smime@imc.org > Subject: RE: S/MIME v3.2 IDs key size text (resend, this time not opaque > signed with 2k key) > Our task is to create a standard that is usable by as many people as > possible while at the same time as setting some minimum operational > security expectations. For interoperability, we need to say "you can > verify signatures created following this spec". For minimum > operational security, we have to pick a size that is reasonable for > the vast majority of users while encouraging software developers to > support all reasonable sizes. > > Please read RFC 3766. If you believe that the numbers in there are > wrong, by all means let the IETF community know. If you believe that > the numbers there are right but you still think that a typical user > needs more than 75 bits of symmetric strength for their signatures, > even though no one has ever done that much effort for even a single > attack in public, please say why. These are interesting points. I believe that the vast majority of users are actually either at government= agencies or financial institutions. The government guys need FIPS 140-2, w= hich is fairly clear about requiring bigger keys (actually the SP that the = IG refers to is), and the FI people need to follow the ANSI X9 recommendati= ons. Both of these require the use of 2K keys Really Soon. Because of this,= I believe that making things reasonable for the vast majority of users mea= ns requiring the support for 2K keys ASAP. I'd also say that what RFC 3766 says is totally irrelevant. The people who = rely on cryptography are the ones that say what an acceptable level of risk= is. In the case of FIs who rely on X9 standards, this means using keys tha= t are fairly big, and may be bigger that RFC 3766 describes. In the case of= government users, this is defined by NIST in SP 800-57. >From the point of view of a cryptographer, the key sizes that they require = may seem a bit big, but then the cryptographers aren't the ones dealing wit= h trillions of dollars of risk, either. 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 m447vr8S003254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 May 2008 00:57: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 m447vrWj003251; Sun, 4 May 2008 00:57: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 mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m447vl0c003194; Sun, 4 May 2008 00:57:52 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 4E64C4804A9; Sun, 4 May 2008 19:57:47 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4l2UCQ95zSPH; Sun, 4 May 2008 19:57:47 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 3076A4804A8; Sun, 4 May 2008 19:57:47 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id AC13A19EC0B9; Sun, 4 May 2008 19:57:46 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JsZ6Q-00057e-JF; Sun, 04 May 2008 19:57:46 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org, pgut001@cs.auckland.ac.nz, phoffman@imc.org Subject: RE: S/MIME v3.2 IDs key size text In-Reply-To: Message-Id: Date: Sun, 04 May 2008 19:57:46 +1200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul Hoffman writes: >At 4:56 PM +1200 5/3/08, Peter Gutmann wrote: >> >>(The "or shorter" attached to the "1024" is also going to prove problematic >>>>with FIPS-evaluated crypto implementations, since you can't do < 1024 bits >>>>for those). >>> >>>That's just plain wrong. Nothing in the FIPS evaluation says that you cannot >>>verify signatures shorter than what they require. >> >>I didn't say you couldn't verify sigs, I said you couldn't get the code to do >>that evaluated because the minimum they'll accept is 1024 bits. In other >>words you'd be using non-evaluated code (or code run in a non-evaluated mode) >>to do the sig. verification. > >I admit that I haven't gone through a FIPS evaluation myself, but what you >say seems wrong. I've gone through several, and talked to numerous others who have as well. It's the usual crapshoot, some labs will allow < 1024-bit keys and some won't. For my own code I've had one lab pass 512-bit keys OK and another one say that any ability to use keys of less than 1024 bits would mean it couldn't be evaluated. In another, more amusing case reported to me by someone else, they got one lab to OK it at 512 bits, then a second lab required them to submit paperwork showing that they blocked all keys of less than 1024 bits, and after they did that the first lab complained that they were failing their tests on 512-bit keys. In the end they just declared that their product didn't support any keys less than 1024 bits and everything was OK. >If someone from NIST or from a test lab wants to chime in here, that would be >grand. What really matters is what the labs in sum total enforce, not what NIST thinks or what one individual lab does. As the above examples show, you can jury-shop your lab to get 512-bit keys passed if you like, but it only works in some cases and to be safe you need to use a minimum key size of 1024 bits. Peter. 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 m4428I2j050371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2008 19:08:18 -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 m4428I5K050370; Sat, 3 May 2008 19:08:18 -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 m4428Er8050339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2008 19:08:16 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <000001c8ad81$00163160$0201a8c0@Wylie> References: <000001c8ad81$00163160$0201a8c0@Wylie> Date: Sat, 3 May 2008 19:08:13 -0700 To: "Turner, Sean P." , From: Paul Hoffman Subject: RE: S/MIME v3.2 IDs key size text Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 8:51 PM -0400 5/3/08, Turner, Sean P. wrote: >I think if we struck ", namely 1024 bits" from the text in the security >considerations that it's still a true statement and we won't have to change >it every time we update the spec. I'm OK with that, but I also feel that if we're updating the minimum mandatory signing length, it is trivial to update the Security Considerations as well. 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 m440tW7c020023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2008 17:55: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 m440tWan020022; Sat, 3 May 2008 17:55: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 m440tU1a020007 for ; Sat, 3 May 2008 17:55:31 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 63842 invoked from network); 4 May 2008 00:55:30 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.231.117.153 with login) by smtp106.biz.mail.re2.yahoo.com with SMTP; 4 May 2008 00:55:29 -0000 X-YMail-OSG: 8suDOCEVM1lEXQ61q2tJO74g08pYt.mAn.sgbWhH.1iHMnpkmX2VIdKkR5QCVswTiGwOLeGYbG7wd7jldMrjuA45JHQyzSOsFiAe0BJvwXg8o2YiOLGBxeKDNDC_qKm7j.I- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: References: Subject: RE: S/MIME v3.2 IDs key size text Date: Sat, 3 May 2008 20:51:28 -0400 Organization: IECA, Inc. Message-ID: <000001c8ad81$00163160$0201a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acisn2OMVeAjgQKaRQq0PXBytb9a6AA4W3Jw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think if we struck ", namely 1024 bits" from the text in the security considerations that it's still a true statement and we won't have to change it every time we update the spec. spt >-----Original Message----- >From: owner-ietf-smime@mail.imc.org >[mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Paul Hoffman >Sent: Friday, May 02, 2008 5:44 PM >To: ietf-smime@imc.org >Subject: RE: S/MIME v3.2 IDs key size text > > >At 6:16 AM +1200 5/3/08, Peter Gutmann wrote: >>"Turner, Sean P." writes: >> >>>A receiving agent needs to be able to verify signatures whose key >>>length is chosen by the signer. For interoperability, a receiving >>>agent MUST be able to verify signatures whose key length is >1024 bits or shorter. >> >>[...] >> >>>Receiving agents are only required to validate signatures >that are the >>>same length as sending agents are required to produce, >namely 1024 bits. >> >>Aren't these mutually exclusive? > >Yes; that's why they are in separate sections. > >>(The "or shorter" attached to the "1024" is also going to prove >>problematic with FIPS-evaluated crypto implementations, since >you can't >>do < 1024 bits for those). > >That's just plain wrong. Nothing in the FIPS evaluation says >that you cannot verify signatures shorter than what they require. > 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 m43MqNqj067312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2008 15:52: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 m43MqNRN067311; Sat, 3 May 2008 15:52: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 smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m43MqLmU067293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 3 May 2008 15:52:22 -0700 (MST) (envelope-from ietf@augustcellars.com) Received: from GALATIONS (unknown [207.202.179.27]) by smtp1.pacifier.net (Postfix) with ESMTP id 1521B6F184; Sat, 3 May 2008 15:52:19 -0700 (PDT) From: "Jim Schaad" To: "'Turner, Sean P.'" , "'Ietf-Smime'" References: <018301c8a3cb$38074bf0$0301a8c0@Wylie> In-Reply-To: <018301c8a3cb$38074bf0$0301a8c0@Wylie> Subject: RE: New ASN.1 modules comments/questions Date: Sat, 3 May 2008 15:52:19 -0700 Message-ID: <0fe601c8ad70$57e77c70$07b67550$@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: Acijyzeq0RMiwCJnRHiuFMdEY7uJtQJkneRg Content-Language: en-us Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sean, Sorry for the delay in getting back to you. I had some work that needed to get finished. Jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf- > smime@mail.imc.org] On Behalf Of Turner, Sean P. > Sent: Monday, April 21, 2008 9:18 AM > To: 'Ietf-Smime' > Subject: New ASN.1 modules comments/questions > > > Jim and Paul, > > Here are some comments/questions on the ASN.1 modules. > > spt > > ------------------- > > The definitions of AlgorithmIdentifier in the PKIX and SMIME modules > are > different - is there a reason for the difference? Does it matter? In > PKIX > it's AlgorithmSet, in SMIME it's InfoObjectSet, in RFC2976 it's IOSet, > in > ANSI X9 docs it's also IOSet, and in X.509 it's SupportedAlgorithms. If > it > matters, then I guess I lean towards what's in RFC2976 since it's > already in > an RFC. There is no effective difference between the two definitions. The two differences are 1) the name of a parameter and 2) comments. The name of the parameter makes no difference. Just as the name of a parameter makes no difference if you are writing a C function. The same is true for comments. > > ------------------- > > In the 3370 section, > > 1. Shouldn't AlgorithmIdentifier be imported from the PKIX module? Long term, AlgorithmIdentifier will be imported from the new Algorithm Information module. So this should become moot. > > 2. You used alg- as tag for hash algs, sig- for signature algs, kea- > for > key agreement algs, alg- for symmetric key encryption algs. I think it > might be easier to figure out which algs go where if the tag matches > the > type of algorithm like mda- for MessageDigestAlgorithms, sa- for > SignatureAlgorithms, and kaa- for KeyAgreementAlgorithms. Thanks for suggesting some potential tags to be used. I agree that we need some short simple notation to mark the different types of algorithm objects. > > 3. Could we change SymmetricKeyEncryptionAlgorithms to just > KeyWrapAlgorithms and use kwa- as the tag? There's also a > KeyWrapAlgorithm > that I think is supposed to be the same as the > SymmetricKeyEncryptionAlgorithms so one or the other can get deleted > (if you > delete the later change SupportKeyWrapAlgorithms to KeyWrapAlgorithms)? I have no problems with this change. There is a minor question here about doing a good job of distinguishing Key Wrap Algorithms and Key Transport Algorithms. I added the Symmetric to the front to distinguish from Key Transport algorithms which, as the KEA algorithm suggest, can also be thought of as Key Encryption algorithms. The use of Key Wrap might be sufficient to distinguish between them, but CMS uses Key Encryption as the name of these types of algorithms. Which is a better way to go? > > 4. Shouldn't SymmetricKeyEncryptionAlgorithms be extensible? > Welcome to a long philosophical discussion. There are two different places where this extensibility can be placed. The two different locations imply different things. This means that depending on how you look at things this should or should not be extensible. If you place the extensibility here, you are saying that we think that this document is going to be updated, and that we are going to add new algorithms to this document. Alternatively, if you place the extensibility in CMS, you are saying that we are going to define new algorithms by creating new documents with new modules and they should be "imported" into the CMS document in one manner or another. The compiler that we are working on has a planned directive to allow for an object to be added to an extensible object set. Part of the question at this point would be as follows. Where should the new algorithm be added, in this document - thus potentially effecting more than just CMS - or in CMS thus limiting where the changes are set. My personal beliefs are: - 1. New algorithms should be added by creating new documents not by updating this document - 2. Changes in algorithm sets should be as narrow as possible - thus the updates should be done in CMS not here. The upshot of this is that I believe this object set is NOT extensible, but the corresponding one in CMS should be extensible. > 5. Do we need to add a MessageAuthenticationCodeAlgorithms for the > hmac > alg? Then we could use maca- in front of the hMAC-SHA1. I have no issues with this. > > 6. Some of the IOSets are {...} (like SignatureAlgorithms) while > others > lists algorithms (like MessageDigestAlgorithms) - shouldn't all of them > list > algorithms or none? This has to do with the fact that the module updates are not finished, but the symbols needed to be defined for different reasons. These will become closed sets with the appropriate algorithm objects in them. > > ------------------- > > In the 3565 section, I think the algorithms need to be defined using > the new > syntax, import ALGORITHM, and define the algs as follows: > > ContentEncryptionAlgorithms ALGORITHM ::= { > cea-aes128-cbc | > cea-aes192-cbc | > cea-aes256-cbc, > ... -- Extensible > } > > cea-aes128-cbc ALGORITHM ::= { > OID id-aes128-CBC PARMS AES-IV } > > cea-aes192-cbc ALGORITHM ::= { > OID id-aes192-CBC PARMS AES-IV } > > cea-aes256-cbc ALGORITHM ::= { > OID id-aes256-CBC PARMS AES-IV } > > KeyWrapAlgorithms ALGORITHM ::= { > kwa-aes128 | > kwa-aes192 | > kwa-aes256, > ... -- Extensible > } > > kwa-aes128 ALGORITHM ::= { > OID id-aes128-wrap PARMS ABSENT } > > kwa-aes192 ALGORITHM ::= { > OID id-aes192-wrap PARMS ABSENT } > > kwa-aes256 ALGORITHM ::= { > OID id-aes256-wrap PARMS ABSENT } > Module has not be updated to reflect what is going on in modules. I was waiting to get the Algorithm Information module finished first. > ------------------- > > In the 3851 section, shouldn't SMimeAttributeSet be extensible? r/{ > attr-smimeCapabilities | attr-encrypKeyPref }/{ attr-smimeCapabilities > | > attr-encrypKeyPref, ... } See discussion above about whether we think we are going to add new attributes to a future version of this document. > > ------------------- > > In the 3852 section, > > 1. OID for PKIX1 module doesn't match the new PKIX asn ID OID - I > think it > should be id-pkix-explict(19) instead of (18). First, at some point we are going to replace all of the module numbers. We have just not yet gotten to that point. Based on the documents that I looked at, the explicit module is 18. > > 2. Are you going to remove the version notations [[3:, [[4:, etc? It is my belief that having the version tags included adds information to the ASN.1 module. Thus I plan on keeping them unless I get some large objections. > > 3. For consistency with 3370, can we change DigestAlgorithmList to > MessageDigestAlgorithms? I don't want these to have the same names. In the long run we will do the following: DigestAlgorithmList ALGORITHM ::= {MessageDigestAlgorithms,...} However I am open to the following: - We create a standardized but descriptive method of naming the sets of algorithms defined in a module - thus in 3370 we might say CMSAlgs-MessageDigestAlgorithm - Do the suggested re-name here. > > 4. For consistency, can we change UnsigedAttributes to > UnsignedAttributesSet and UnprotectedAttributes to > UnprotectedAttribuesSet? No problems > > 5. In AuthenticatedData, SupportedAttributes is used in AuthAttributes > and > UnauthAttributes. In AuthAttributes, can we change SupportAttributes to > AuthAttributesSet and in UnauthAttributes can we change > SupportedAttributes > to UnauthAttributesSet? No problems > > 6. For consistency with the 3370 section, can we change > SignatureAlgorithmList to SignatureAlgorithms, DigestAlgorithmList to > MessageDigestAlgorithms, KeyAgreementAlgorithmList to > KeyAgreementAlgorithms, and ContentEncryptionAlgorithmLists to > ContentEncryptionAlgorithms? See above note > > 7. Can we change KeyDerivationAlgorithmIdentifier to use > KeyDerivationAlgorithms instead of AlgorithmList? Yes this should be done. > > 8. Can we change MessageAuthenticationCodeAlgorithm to use > MessageAuthenticationCodeAlgorithms instead of AlgorithmList? > Yes this should be done > 9. Don't we want to define an OriginatorPKAlgorithms instead of using > AlgorithmList in OriginatorPublicKey: > > OriginatorPublicKey ::= SEQUENCE { > algorithm AlgorithmIdentifier {{OriginatorPKAlgorithms}}, > publicKey BIT STRING > } > > OriginatorPKAlgorithms ALGORITHM ::= { > ... -- Extensible > } > Yes this should be done in the end. > 10. For consistency, can we change KeyEncryptionAlgorithmList to be > KeyEncryptionAlgorithms? The above note about matching the name in 3370 needs to be taken into account. I used List (but could have used Set) but I am not wedded to this. I worry about using an 's' at the end as this could be a sequence of algorithms as well. There exists a potential confusion in the future. > > ------------------- > > In the 4108 section, can we make FirwareContentTypes and > FirmwareSignedAttrs > extensible? See discussion on the question - do we think this module will be updated in the future. > > ------------------- > > In the 4998 section, > > 1. Shouldn't we constrain the digestAlgorithms and digestAlgorithm? Probably - this is actually not a CMS module. I was waiting to figure out how algorithms are actually done first > > 2. Should the import for Attribute come from PKIX or RFC3852 update > module? This has been moved to the PKIX-COMMON module > > 3. Why is Extensions and EXTENSION imported? To use a single standardized version, as with Attribute > > ------------------- > > In the 5035 section, > > 1. Why is Extensions and EXTENSION imported? > See above > 2. Should the import for Attribute come from PKIX or RFC3852 update > module? > See above > 3. OID for PKIX1 module doesn't match the new PKIX asn ID OID - I > think it > should be id-pkix-explict(19) instead of (18). > See above note > 4. Should EssSignedAttributes be SignedAttributes? Should it also be > extensible? > See both above philosophy discussion and discussions on naming of items > 5. Should EssContentTypes be just ContentSet? > Same as above. > 6. Is the note about the identical SecurityCategories encoding > required > anymore? I have no opinion one way or the other on this. Being conservative says it stays. > > 7. Shouldn't we say HashAlgorithms ::= MessageDigestAlgorithms instead > of > HashAlgorithms ::= AlgorithmIdentifier {{...}}? Yes it should - it also needs to import it - which is a new module. > > 8. Shouldn't we import the shaa256 alg? > Yes - it would be wise - I did not do it originally so that I did not import a new module. > ------------------- > > In the 5084 section, we should import ALGORITHM from PKIX and define > the > algorithms as follows: > > ContentEncryptionAlgorithms ALGORITHM ::= { > cea-aes128-ccm | > cea-aes192-ccm | > cea-aes256-ccm | > cea-aes128-gcm | > cea-aes128-gcm | > cea-aes128-gcm, > ... -- Extensible > } > > cea-aes128-ccm ALGORITHM ::= { > OID id-aes128-CCM PARMS CCMParameters } > > cea-aes192-ccm ALGORITHM ::= { > OID id-aes192-CCM PARMS CCMParameters } > > cea-aes256-ccm ALGORITHM ::= { > OID id-aes256-CCM PARMS CCMParameters } > > cea-aes128-gcm ALGORITHM ::= { > OID id-aes128-GCM PARMS GCMParameters } > > cea-aes192-gcm ALGORITHM ::= { > OID id-aes192-GCM PARMS GCMParameters } > > cea-aes256-gcm ALGORITHM ::= { > OID id-aes256-GCM PARMS GCMParameters } This is waiting on the new Algoirthm Information module. 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 m43JBP5K067499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2008 12:11: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 m43JBPkm067498; Sat, 3 May 2008 12:11:25 -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 m43JBMWV067473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 3 May 2008 12:11:24 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <001801c8ad4e$7c0bc6a0$02b5a8c0@tony> References: <001801c8ad4e$7c0bc6a0$02b5a8c0@tony> Date: Sat, 3 May 2008 12:11:20 -0700 To: From: Paul Hoffman Subject: RE: S/MIME v3.2 IDs key size text (resend, this time not opaque signed with 2k key) 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:49 PM -0400 5/3/08, Tony Capel wrote: >1A) Both signing and verifying. > >Verisign has been issuing both 1k and 2k single keypair certs for some >time, 2k is becoming common in many product specifications and recommended >by many reputable authorities. How is this relevant to the discussion thread? There are lots of communities that use (and even require) higher security than what is in the current spec. For example, the US Department of Defense is now mandating the use of elliptic curve cryptography for digital signatures. Using them as the base, instead of VeriSign, we would have a mandatory-to-implement requirement for ECC. I do not imagine you would support that, so I don't see why picking one product (the 2K certs) from one vendor should affect our decision for the mandatory-to-implement requirements as long as we make it clear that it is likely that any application will probably want to do more than that. >So if we wish to guarantee a minimum level of "out-of-the-box" >interoperability from a box which has a simplistic specification >"compliant to smime v3.2"; then we should include a mandate for 2k and >lower support for all operations to meet today's requirement. This completely confuses mandatory-to-implement and optional. VeriSign uses one of the options available to them, namely longer key sizes. They also use the mandatory-to-implement size, and they still distribute their own certificates using much-lower-than-mandatory sizes. None of that is relevant to anyone other than VeriSign and their customers. Our task is to create a standard that is usable by as many people as possible while at the same time as setting some minimum operational security expectations. For interoperability, we need to say "you can verify signatures created following this spec". For minimum operational security, we have to pick a size that is reasonable for the vast majority of users while encouraging software developers to support all reasonable sizes. Please read RFC 3766. If you believe that the numbers in there are wrong, by all means let the IETF community know. If you believe that the numbers there are right but you still think that a typical user needs more than 75 bits of symmetric strength for their signatures, even though no one has ever done that much effort for even a single attack in public, please say why. 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 m43Io2xV058953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2008 11:50:02 -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 m43Io2oY058952; Sat, 3 May 2008 11:50:02 -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-08.primus.ca (mail.tor.primus.ca [216.254.136.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m43Io1Jt058923; Sat, 3 May 2008 11:50:01 -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-08.primus.ca with esmtps (TLSv1:RC4-MD5:128) (Exim 4.63) (envelope-from ) id 1JsMo4-0004iP-1k; Sat, 03 May 2008 14:50:00 -0400 From: "Tony Capel" To: "'Paul Hoffman'" , Subject: RE: S/MIME v3.2 IDs key size text (resend, this time not opaque signed with 2k key) Date: Sat, 3 May 2008 14:49:57 -0400 Message-ID: <001801c8ad4e$7c0bc6a0$02b5a8c0@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: Importance: Normal Thread-Index: AcisnoQIC2w21EFkR9aMbnt2Mc3yWgArqPAg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul: 1A) Both signing and verifying. Verisign has been issuing both 1k and 2k single keypair certs for some time, 2k is becoming common in many product specifications and recommended by many reputable authorities. I communicate today within a community of 2k and lower certificate holders not 1K and lower holders. I have a 2k "off-the-shelf" cert from Verisign, I cannot generate 1k signatures, so anyone I send to must be able to verify 2k signatures. So verify 2k support is required today. It is true that users who only intend to use 1k certs could get away with software which cannot sign using 2k keys; but I think this is a pretty subtle detail which would be lost in the noise of most specifications. 1B) And encryption and decryption as well. Furthermore, since those Versign certs are single keypair, I need 2k encrypt/decrypt since obviously the same keypair is used. Those using multiple keypair infrastructures with separate signing and encryption certs could use differing sizes, but in my experience the infrastructures themselves tend to have the same specification for both sign and encrypt (sign/verify and decrypt/encrypt). For encryption of course the keysize is specified by the destination cert; so if anyone in my community has 2k keys, I must be able to encrypt with 2k keys. So encrypt support for 2k keys is required today. Again, 1k only support for decryption would be lost in the noise. So if we wish to guarantee a minimum level of "out-of-the-box" interoperability from a box which has a simplistic specification "compliant to smime v3.2"; then we should include a mandate for 2k and lower support for all operations to meet today's requirement. 2) Support beyond the mandatory. I agree that support beyond 2k should be optional. I am sorry I misused the word "SHOULD", I operate in several standardization arenas and rfc2119 is not a universal standard!! I meant OPTIONAL or MAY for the larger sizes. The reason for my identifying the specific 3k and 4k values was an attempt to address an earlier thread where 4k and larger keysizes were proposed - which led to a discussion of denial of service attacks by senders specifying large keysizes - and then this led to comments about improper modulus selection, etc. etc.... The origin of the earlier thread was concern about leaving larger keysizes completely open (even as OPTIONAL). I prefer to leave this issue, if it remains an issue, to Peter and the others who contributed to that thread. (I would just note that in my reading 3k and 4k certs are mentioned, but it is not clear to me that there is a future beyond 4k RSA with competition from other algorithms.) Tony | -----Original Message----- | From: owner-ietf-smime@mail.imc.org | [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Paul Hoffman | Sent: May 2, 2008 5:44 PM | To: ietf-smime@imc.org | Subject: RE: S/MIME v3.2 IDs key size text | | | | At 2:35 PM -0400 5/2/08, Tony Capel wrote: | >I think the minimum supported size needs to be 2048 because: | | Please be more specific. Supported for what? Signing, | verifying, or both? | | >1) Since at least April 2007 (over a year ago) Verisign has been | >issuing certs with 2048 keys (I believe this is selectable when | >enrolling) (although the root cert is only 1024!). | >2) NIST is recommending 2048 by end of 2008 for signatures and key | >transport for | >some apps [SP-800-78-1 Table 3.1]. | >3) Many/most hardware tokens (e.g. Safenet, Gem, Aladdin) | are supporting 1024 | >and 2048 (only). | | The wording clearly says that you should expect to validate larger | keys, which are covered by those three data points. | | Your last point (hardware tokens signing at 1024) is exactly why I | think mandating the ability to sign at least 1024 bits is a good idea. | | >As far as going larger than 2048, in my brief survey, while there | >appears to be | >a small level of interest in 3072 (and even 4096), beyond that many | >appear to be | >recommending a switch to ECC because of the exponentially rising | >power/cpu costs | >for larger RSA sizes (e.g. NSA Suite B). | | The current text encourages being able to verify at any level, not | just 1024 or even 2048. | | >So I would suggest making 2048 and smaller mandatory. And using a | >sentence like: | >" Note that receiving agents may see signatures whose key length is | >longer than | >2048 | > bits in the future, and support for lengths of 3072 and | 4078 SHOULD | >be provided | > | > to verify those signatures." | | I fully disagree. We are talking about interoperability here, not | best practice. We should not be mandating that receivers be able to | verify things that beyond what is mandated for signers. If you want | to change the length of what signers are required to do, that's fine, | I would want both sides to be accordance. But until then, saying "you | must be able to verify something larger than what you can sign" | doesn't make sense from an interoperability standpoint. | | Also, we should not mandate SHOULD-level requirements for particular | size keys. For verification, specific bit-lengths are not important: | it is the maximum key length. | | >Or | > | > "... for lengths up to and including 4078 SHOULD ..." | > | >to address optional support. | | This doesn't seem to be a good reading of RFC 2119. | 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 m43I8kFl039561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2008 11:08:46 -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 m43I8j6x039560; Sat, 3 May 2008 11:08: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-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 m43I8iLx039522; Sat, 3 May 2008 11:08:45 -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 1JsMA5-0001MT-33; Sat, 03 May 2008 14:08:42 -0400 From: "Tony Capel" To: "'Paul Hoffman'" , Subject: RE: S/MIME v3.2 IDs key size text Date: Sat, 3 May 2008 14:08:38 -0400 Message-ID: <000801c8ad48$b6b7f9a0$02b5a8c0@tony> MIME-Version: 1.0 Content-Type: application/pkcs7-mime; smime-type=signed-data; name="smime.p7m" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7m" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6838 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: AcisnoQIC2w21EFkR9aMbnt2Mc3yWgApnC8g Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEU0NvbnRl bnQtVHlwZTogdGV4dC9wbGFpbjsNCgljaGFyc2V0PSJ1cy1hc2NpaSINCkNvbnRlbnQtVHJhbnNm ZXItRW5jb2Rpbmc6IDdiaXQNCg0KBIIVTw0KUGF1bDoNCg0KMUEpIEJvdGggc2lnbmluZyBhbmQg dmVyaWZ5aW5nLg0KDQpWZXJpc2lnbiBoYXMgYmVlbiBpc3N1aW5nIGJvdGggMWsgYW5kIDJrIHNp bmdsZSBrZXlwYWlyIGNlcnRzIGZvciBzb21lDQp0aW1lLCAyayBpcyBiZWNvbWluZyBjb21tb24g aW4gbWFueSBwcm9kdWN0IHNwZWNpZmljYXRpb25zIGFuZCByZWNvbW1lbmRlZA0KYnkgbWFueSBy ZXB1dGFibGUgYXV0aG9yaXRpZXMuDQoNCkkgY29tbXVuaWNhdGUgdG9kYXkgd2l0aGluIGEgY29t bXVuaXR5IG9mIDJrIGFuZCBsb3dlciBjZXJ0aWZpY2F0ZSBob2xkZXJzDQpub3QgMUsgYW5kIGxv d2VyIGhvbGRlcnMuICBJIGhhdmUgYSAyayAib2ZmLXRoZS1zaGVsZiIgY2VydCBmcm9tIFZlcmlz aWduLA0KSSBjYW5ub3QgZ2VuZXJhdGUgMWsgc2lnbmF0dXJlcywgc28gYW55b25lIEkgc2VuZCB0 byBtdXN0IGJlIGFibGUgdG8NCnZlcmlmeSAyayBzaWduYXR1cmVzLiAgU28gdmVyaWZ5IDJrIHN1 cHBvcnQgaXMgcmVxdWlyZWQgdG9kYXkuICBJdCBpcyB0cnVlDQp0aGF0IHVzZXJzIHdobyBvbmx5 IGludGVuZCB0byB1c2UgMWsgY2VydHMgY291bGQgZ2V0IGF3YXkgd2l0aCBzb2Z0d2FyZQ0Kd2hp Y2ggY2Fubm90IHNpZ24gdXNpbmcgMmsga2V5czsgYnV0IEkgdGhpbmsgdGhpcyBpcyBhIHByZXR0 eSBzdWJ0bGUNCmRldGFpbCB3aGljaCB3b3VsZCBiZSBsb3N0IGluIHRoZSBub2lzZSBvZiBtb3N0 IHNwZWNpZmljYXRpb25zLg0KDQoxQikgQW5kIGVuY3J5cHRpb24gYW5kIGRlY3J5cHRpb24gYXMg d2VsbC4NCg0KRnVydGhlcm1vcmUsIHNpbmNlIHRob3NlIFZlcnNpZ24gY2VydHMgYXJlIHNpbmds ZSBrZXlwYWlyLCBJIG5lZWQgMmsNCmVuY3J5cHQvZGVjcnlwdCBzaW5jZSBvYnZpb3VzbHkgdGhl IHNhbWUga2V5cGFpciBpcyB1c2VkLiAgVGhvc2UgdXNpbmcNCm11bHRpcGxlIGtleXBhaXIgaW5m cmFzdHJ1Y3R1cmVzIHdpdGggc2VwYXJhdGUgc2lnbmluZyBhbmQgZW5jcnlwdGlvbg0KY2VydHMg Y291bGQgdXNlIGRpZmZlcmluZyBzaXplcywgYnV0IGluIG15IGV4cGVyaWVuY2UgdGhlIGluZnJh c3RydWN0dXJlcw0KdGhlbXNlbHZlcyB0ZW5kIHRvIGhhdmUgdGhlIHNhbWUgc3BlY2lmaWNhdGlv biBmb3IgYm90aCBzaWduIGFuZCBlbmNyeXB0DQooc2lnbi92ZXJpZnkgYW5kIGRlY3J5cHQvZW5j cnlwdCkuDQoNCkZvciBlbmNyeXB0aW9uIG9mIGNvdXJzZSB0aGUga2V5c2l6ZSBpcyBzcGVjaWZp ZWQgYnkgdGhlIGRlc3RpbmF0aW9uIGNlcnQ7DQpzbyBpZiBhbnlvbmUgaW4gbXkgY29tbXVuaXR5 IGhhcyAyayBrZXlzLCBJIG11c3QgYmUgYWJsZSB0byBlbmNyeXB0IHdpdGgNCjJrIGtleXMuICBT byBlbmNyeXB0IHN1cHBvcnQgZm9yIDJrIGtleXMgaXMgcmVxdWlyZWQgdG9kYXkuICBBZ2Fpbiwg MWsNCm9ubHkgc3VwcG9ydCBmb3IgZGVjcnlwdGlvbiB3b3VsZCBiZSBsb3N0IGluIHRoZSBub2lz ZS4NCg0KU28gaWYgd2Ugd2lzaCB0byBndWFyYW50ZWUgYSBtaW5pbXVtIGxldmVsIG9mICJvdXQt b2YtdGhlLWJveCINCmludGVyb3BlcmFiaWxpdHkgZnJvbSBhIGJveCB3aGljaCBoYXMgYSBzaW1w bGlzdGljIHNwZWNpZmljYXRpb24NCiJjb21wbGlhbnQgdG8gc21pbWUgdjMuMiI7IHRoZW4gd2Ug c2hvdWxkIGluY2x1ZGUgYSBtYW5kYXRlIGZvciAyayBhbmQNCmxvd2VyIHN1cHBvcnQgZm9yIGFs bCBvcGVyYXRpb25zIHRvIG1lZXQgdG9kYXkncyByZXF1aXJlbWVudC4NCg0KMikgU3VwcG9ydCBi ZXlvbmQgdGhlIG1hbmRhdG9yeS4NCg0KSSBhZ3JlZSB0aGF0IHN1cHBvcnQgYmV5b25kIDJrIHNo b3VsZCBiZSBvcHRpb25hbC4gIEkgYW0gc29ycnkgSSBtaXN1c2VkDQp0aGUgd29yZCAiU0hPVUxE IiwgSSBvcGVyYXRlIGluIHNldmVyYWwgc3RhbmRhcmRpemF0aW9uIGFyZW5hcyBhbmQgcmZjMjEx OQ0KaXMgbm90IGEgdW5pdmVyc2FsIHN0YW5kYXJkISEgIEkgbWVhbnQgT1BUSU9OQUwgb3IgTUFZ IGZvciB0aGUgbGFyZ2VyDQpzaXplcy4NCg0KVGhlIHJlYXNvbiBmb3IgbXkgaWRlbnRpZnlpbmcg dGhlIHNwZWNpZmljIDNrIGFuZCA0ayB2YWx1ZXMgd2FzIGFuIGF0dGVtcHQNCnRvIGFkZHJlc3Mg YW4gZWFybGllciB0aHJlYWQgd2hlcmUgNGsgYW5kIGxhcmdlciBrZXlzaXplcyB3ZXJlIHByb3Bv c2VkIC0NCndoaWNoIGxlZCB0byBhIGRpc2N1c3Npb24gb2YgZGVuaWFsIG9mIHNlcnZpY2UgYXR0 YWNrcyBieSBzZW5kZXJzDQpzcGVjaWZ5aW5nIGxhcmdlIGtleXNpemVzIC0gYW5kIHRoZW4gdGhp cyBsZWQgdG8gY29tbWVudHMgYWJvdXQgaW1wcm9wZXINCm1vZHVsdXMgc2VsZWN0aW9uLCBldGMu IGV0Yy4uLi4NCg0KVGhlIG9yaWdpbiBvZiB0aGUgZWFybGllciB0aHJlYWQgd2FzIGNvbmNlcm4g YWJvdXQgbGVhdmluZyBsYXJnZXIga2V5c2l6ZXMNCmNvbXBsZXRlbHkgb3BlbiAoZXZlbiBhcyBP UFRJT05BTCkuIEkgcHJlZmVyIHRvIGxlYXZlIHRoaXMgaXNzdWUsIGlmIGl0DQpyZW1haW5zIGFu IGlzc3VlLCB0byBQZXRlciBhbmQgdGhlIG90aGVycyB3aG8gY29udHJpYnV0ZWQgdG8gdGhhdCB0 aHJlYWQuDQooSSB3b3VsZCBqdXN0IG5vdGUgdGhhdCBpbiBteSByZWFkaW5nIDNrIGFuZCA0ayBj ZXJ0cyBhcmUgbWVudGlvbmVkLCBidXQNCml0IGlzIG5vdCBjbGVhciB0byBtZSB0aGF0IHRoZXJl IGlzIGEgZnV0dXJlIGJleW9uZCA0ayBSU0Egd2l0aA0KY29tcGV0aXRpb24gZnJvbSBvdGhlciBh bGdvcml0aG1zLikNCg0KVG9ueQ0KDQp8IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQp8IEZy b206IG93bmVyLWlldGYtc21pbWVAbWFpbC5pbWMub3JnDQp8IFttYWlsdG86b3duZXItaWV0Zi1z bWltZUBtYWlsLmltYy5vcmddIE9uIEJlaGFsZiBPZiBQYXVsIEhvZmZtYW4NCnwgU2VudDogTWF5 IDIsIDIwMDggNTo0NCBQTQ0KfCBUbzogaWV0Zi1zbWltZUBpbWMub3JnDQp8IFN1YmplY3Q6IFJF OiBTL01JTUUgdjMuMiBJRHMga2V5IHNpemUgdGV4dA0KfA0KfA0KfA0KfCBBdCAyOjM1IFBNIC0w NDAwIDUvMi8wOCwgVG9ueSBDYXBlbCB3cm90ZToNCnwgPkkgdGhpbmsgdGhlIG1pbmltdW0gc3Vw cG9ydGVkIHNpemUgbmVlZHMgdG8gYmUgMjA0OCBiZWNhdXNlOg0KfA0KfCBQbGVhc2UgYmUgbW9y ZSBzcGVjaWZpYy4gU3VwcG9ydGVkIGZvciB3aGF0PyBTaWduaW5nLA0KfCB2ZXJpZnlpbmcsIG9y IGJvdGg/DQp8DQp8ID4xKSBTaW5jZSBhdCBsZWFzdCBBcHJpbCAyMDA3IChvdmVyIGEgeWVhciBh Z28pIFZlcmlzaWduIGhhcyBiZWVuDQp8ID5pc3N1aW5nIGNlcnRzIHdpdGggMjA0OCBrZXlzIChJ IGJlbGlldmUgdGhpcyBpcyBzZWxlY3RhYmxlIHdoZW4NCnwgPmVucm9sbGluZykgKGFsdGhvdWdo IHRoZSByb290IGNlcnQgaXMgb25seSAxMDI0ISkuDQp8ID4yKSBOSVNUIGlzIHJlY29tbWVuZGlu ZyAyMDQ4IGJ5IGVuZCBvZiAyMDA4IGZvciBzaWduYXR1cmVzIGFuZCBrZXkNCnwgPnRyYW5zcG9y dCBmb3INCnwgPnNvbWUgYXBwcyBbU1AtODAwLTc4LTEgVGFibGUgMy4xXS4NCnwgPjMpIE1hbnkv bW9zdCBoYXJkd2FyZSB0b2tlbnMgKGUuZy4gU2FmZW5ldCwgR2VtLCBBbGFkZGluKQ0KfCBhcmUg c3VwcG9ydGluZyAxMDI0DQp8ID5hbmQgMjA0OCAob25seSkuDQp8DQp8IFRoZSB3b3JkaW5nIGNs ZWFybHkgc2F5cyB0aGF0IHlvdSBzaG91bGQgZXhwZWN0IHRvIHZhbGlkYXRlIGxhcmdlcg0KfCBr ZXlzLCB3aGljaCBhcmUgY292ZXJlZCBieSB0aG9zZSB0aHJlZSBkYXRhIHBvaW50cy4NCnwNCnwg WW91ciBsYXN0IHBvaW50IChoYXJkd2FyZSB0b2tlbnMgc2lnbmluZyBhdCAxMDI0KSBpcyBleGFj dGx5IHdoeSBJDQp8IHRoaW5rIG1hbmRhdGluZyB0aGUgYWJpbGl0eSB0byBzaWduIGF0IGxlYXN0 IDEwMjQgYml0cyBpcyBhIGdvb2QgaWRlYS4NCnwNCnwgPkFzIGZhciBhcyBnb2luZyBsYXJnZXIg dGhhbiAyMDQ4LCBpbiBteSBicmllZiBzdXJ2ZXksIHdoaWxlIHRoZXJlDQp8ID5hcHBlYXJzIHRv IGJlDQp8ID5hIHNtYWxsIGxldmVsIG9mIGludGVyZXN0IGluIDMwNzIgKGFuZCBldmVuIDQwOTYp LCBiZXlvbmQgdGhhdCBtYW55DQp8ID5hcHBlYXIgdG8gYmUNCnwgPnJlY29tbWVuZGluZyBhIHN3 aXRjaCB0byBFQ0MgYmVjYXVzZSBvZiB0aGUgZXhwb25lbnRpYWxseSByaXNpbmcNCnwgPnBvd2Vy L2NwdSBjb3N0cw0KfCA+Zm9yIGxhcmdlciBSU0Egc2l6ZXMgKGUuZy4gTlNBIFN1aXRlIEIpLg0K fA0KfCBUaGUgY3VycmVudCB0ZXh0IGVuY291cmFnZXMgYmVpbmcgYWJsZSB0byB2ZXJpZnkgYXQg YW55IGxldmVsLCBub3QNCnwganVzdCAxMDI0IG9yIGV2ZW4gMjA0OC4NCnwNCnwgPlNvIEkgd291 bGQgc3VnZ2VzdCBtYWtpbmcgMjA0OCBhbmQgc21hbGxlciBtYW5kYXRvcnkuIEFuZCB1c2luZyBh DQp8ID5zZW50ZW5jZSBsaWtlOg0KfCA+IiBOb3RlIHRoYXQgcmVjZWl2aW5nIGFnZW50cyBtYXkg c2VlIHNpZ25hdHVyZXMgd2hvc2Uga2V5IGxlbmd0aCBpcw0KfCA+bG9uZ2VyIHRoYW4NCnwgPjIw NDgNCnwgPiAgYml0cyBpbiB0aGUgZnV0dXJlLCBhbmQgc3VwcG9ydCBmb3IgbGVuZ3RocyBvZiAz MDcyIGFuZA0KfCA0MDc4IFNIT1VMRA0KfCA+YmUgcHJvdmlkZWQNCnwgPg0KfCA+ICB0byB2ZXJp ZnkgdGhvc2Ugc2lnbmF0dXJlcy4iDQp8DQp8IEkgZnVsbHkgZGlzYWdyZWUuIFdlIGFyZSB0YWxr aW5nIGFib3V0IGludGVyb3BlcmFiaWxpdHkgaGVyZSwgbm90DQp8IGJlc3QgcHJhY3RpY2UuIFdl IHNob3VsZCBub3QgYmUgbWFuZGF0aW5nIHRoYXQgcmVjZWl2ZXJzIGJlIGFibGUgdG8NCnwgdmVy aWZ5IHRoaW5ncyB0aGF0IGJleW9uZCB3aGF0IGlzIG1hbmRhdGVkIGZvciBzaWduZXJzLiBJZiB5 b3Ugd2FudA0KfCB0byBjaGFuZ2UgdGhlIGxlbmd0aCBvZiB3aGF0IHNpZ25lcnMgYXJlIHJlcXVp cmVkIHRvIGRvLCB0aGF0J3MgZmluZSwNCnwgSSB3b3VsZCB3YW50IGJvdGggc2lkZXMgdG8gYmUg YWNjb3JkYW5jZS4gQnV0IHVudGlsIHRoZW4sIHNheWluZyAieW91DQp8IG11c3QgYmUgYWJsZSB0 byB2ZXJpZnkgc29tZXRoaW5nIGxhcmdlciB0aGFuIHdoYXQgeW91IGNhbiBzaWduIg0KfCBkb2Vz bid0IG1ha2Ugc2Vuc2UgZnJvbSBhbiBpbnRlcm9wZXJhYmlsaXR5IHN0YW5kcG9pbnQuDQp8DQp8 IEFsc28sIHdlIHNob3VsZCBub3QgbWFuZGF0ZSBTSE9VTEQtbGV2ZWwgcmVxdWlyZW1lbnRzIGZv ciBwYXJ0aWN1bGFyDQp8IHNpemUga2V5cy4gRm9yIHZlcmlmaWNhdGlvbiwgc3BlY2lmaWMgYml0 LWxlbmd0aHMgYXJlIG5vdCBpbXBvcnRhbnQ6DQp8IGl0IGlzIHRoZSBtYXhpbXVtIGtleSBsZW5n dGguDQp8DQp8ID5Pcg0KfCA+DQp8ID4gICIuLi4gZm9yIGxlbmd0aHMgdXAgdG8gYW5kIGluY2x1 ZGluZyA0MDc4IFNIT1VMRCAuLi4iDQp8ID4NCnwgPnRvIGFkZHJlc3Mgb3B0aW9uYWwgc3VwcG9y dC4NCnwNCnwgVGhpcyBkb2Vzbid0IHNlZW0gdG8gYmUgYSBnb29kIHJlYWRpbmcgb2YgUkZDIDIx MTkuDQp8DQoEAAAAAAAAAKCCClIwggTMMIIENaADAgECAhAcrp1rmvTmLyKKo9p0YWweMA0GCSqG SIb3DQEBBQUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UE CxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNTEw MjgwMDAwMDBaFw0xNTEwMjcyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDJ36zn 6vj4AxTEAJLVwX42wjzvfHIVy8CrjD0clc5vHhAsPwDtlybmtsfmrUMdP6SHR0dMPlT4bPjH/LGe vTBwvJexAwXqlfGtQMVEeksFovJg/Nc6ZWLv/xB7ola7xU5wLdaiHzztsELoXo1XIaymmdkR6dIa B8B0R0IL/MU06v3muiTRHQgVN6LXc88BQS9jsjo/vqUabvTJSls9laYVuzUCGfnU77yPDnF2WbtL tj7W/FoW9NYOifJJ/mwM7RXp2Yh1nHnOYCfdua11zi9zlXpAOoV1SbC432i8q80TgoURUKPgPAuu wApTzdcwb4UyRhvkSRDCbOKvH3n/27S1AgMBAAGjggGEMIIBgDASBgNVHRMBAf8ECDAGAQH/AgEA MEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWk IzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps 1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2Ex LmNybDCBgQYDVR0jBHoweKFjpGEwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5ghEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQUFAAOBgQCxL9mW4ZKi7oFg5cgqIPvh ZyzWAJhTowIb6ZBL+BhEnw9G9/qg/tMdGKPSvxzs1hmfSk1D+Mq7vhOASQXdIXMzV8JCWr76AJOy 5gQxkU5dPPBzBTdj67+DWZj9Zt7phjKakik8Oq5U2qYSUbGPyMrTR3jm26Uehwbj0RTAwiH2ujCC BX4wggRmoAMCAQICEESSWjobm8B74KlIfva/2j8wDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0 d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y cGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjAeFw0wODA0MTcwMDAwMDBa Fw0wOTA0MjAyMzU5NTlaMIIBFTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90 IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBT ZXJ2aWNlMRowGAYDVQQDFBFBLkMuIChUb255KSBDYXBlbDEgMB4GCSqGSIb3DQEJARYRY2FwZWxA Y29tZ2F0ZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtfsxOpz6QFfItcBlg xYSH9UbbQaogvaigfZAV45h+fnjVJ+n2zUA6XHOx7XwRZt8EgFcA4aSthXF3evO8DVqKBZcwwBcN 7ylVioSRlDD/TUvXScF+Uh77iC9+9cCN5+mWtNcf1rrBu3pLpViYObKS65JwxinyF9t2AhOLbkVZ hs7b9aKQHq6qAMvQhskxzfdr404pJUKVJ7gGoZOOv1uA3KQdKszXvkG5plO3eNNTaG74JyXTVuLE w/5/RDfaEtD3ayNSBozXWFoGkkD6qCMYtVYhbZFe1JFHU9eJT5Ps5cNmQ3qT43iM/96lqs81f8or ERTHMSvOt0gEJx02eRqZAgMBAAGjgf4wgfswCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG +EUBBxcDMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0P BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAwBgpghkgBhvhFAQYHBCIWIDcx NThjMjkzOGUyZDFkMGRkMTljMTA0MzAyN2QzYjFlMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9J bmRDMURpZ2l0YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDANBgkqhkiG 9w0BAQUFAAOCAQEApfrZkVZZ2pIl60wajeIbTEMslpmB3iHiD7joNe73Ipw+CWfhKKK/kmaSxSRH aKuIOsS2YMM4NHUQkdDA+/BRpBpVHEvdoghwsMh1RLmElt6iQcbnMCNVxvC/36F5loFfSp4TRTVJ GX+EH6It+F4faK88hEQXNNytqLQMHdgX6XSZlnj3M2BhhMUHkxNl7GPNHEkhOQK1J/x7bTx5YgoM pks8eKeO+tuM3GUYeGvy8SsOuWf+1hDaMotfIASiz1Y0z6CL/NImCFhOmMIO9R8z4HitRU5/MFsO lyxcGtxUbp+S9tDJ0bVCNhqvViIgnxCWJ8s4iguwImF4qviYNE9TCzGCBPQwggTwAgEBMIHyMIHd MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNV BAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEESSWjob m8B74KlIfva/2j8wCQYFKw4DAhoFAKCCAtYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDgwNTAzMTgwODM3WjAjBgkqhkiG9w0BCQQxFgQUIaMpec9DF9aLMxAkAs1f qEuUBQYwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAHBgUrDgMCGjAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwCgYIKoZIhvcNAgUwggED BgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNj cmliZXIgQ0EgLSBHMgIQRJJaOhubwHvgqUh+9r/aPzCCAQUGCyqGSIb3DQEJEAILMYH1oIHyMIHd MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNV BAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEESSWjob m8B74KlIfva/2j8wDQYJKoZIhvcNAQEBBQAEggEAQ1TJf8EYPBfuElsfR+POqJaAJQ+lddH7GVDE 8JsYJOJODQIfdW9EgbrX69A89DJzLe6HNIZ3LIXg3V89F+xOWvEN5lyAz1uJDjwEZiCu1YQm0kpR f5AbGDcgshkiiedeAbhDtsFVk5GKFaYbkEB7aNQ6/89VA2A3SlCzjy0PyIL9bGPUzCqfm0O3YWVu UKb2+tegh9v6Rc8aofk42pKW282AKhTMXGm5eOyvymwkDVmBgrCW6qpS06h5m7b3sqx/w7rljflJ E/PyZ0YkU+19Za4AmIHA6K7Vo7Ipf/chyNe4UroTgEBEaVOE0DcqNZtesADfvtvoPHfYfz1j5NiE FgAAAAAAAA== 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 m43Fnltj079961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2008 08:49: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 m43Fnlcq079960; Sat, 3 May 2008 08:49: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 [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 m43FnQAv079815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2008 08:49:27 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sat, 3 May 2008 08:49:25 -0700 To: pgut001@cs.auckland.ac.nz (Peter Gutmann), ietf-smime@imc.org From: Paul Hoffman Subject: RE: S/MIME v3.2 IDs key size text Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 4:56 PM +1200 5/3/08, Peter Gutmann wrote: >How does this reconcile them? Do we get to choose which ones we want? You follow the MUST, not the "if you care about doing things flexibly, you also do this". This is the same as for almost any IETF standard. > >>(The "or shorter" attached to the "1024" is also going to prove problematic >>>with FIPS-evaluated crypto implementations, since you can't do < 1024 bits >>>for those). >> >>That's just plain wrong. Nothing in the FIPS evaluation says that you cannot >>verify signatures shorter than what they require. > >I didn't say you couldn't verify sigs, I said you couldn't get the code to do >that evaluated because the minimum they'll accept is 1024 bits. In other >words you'd be using non-evaluated code (or code run in a non-evaluated mode) >to do the sig. verification. I admit that I haven't gone through a FIPS evaluation myself, but what you say seems wrong. .I assume that verifying code does not have different code paths for different sizes of keys being verified, so the evaluated code works for the mandated sizes and others. Even if you structured your code along key sizes, the "wrong" sizes would be non-evaluated, and the "right" sizes would be evaluated. If someone from NIST or from a test lab wants to chime in here, that would be grand. 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 m434urP9078813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 21:56: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 m434urvi078812; Fri, 2 May 2008 21:56: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 mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m434ueQk078705; Fri, 2 May 2008 21:56:52 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id CC4374806D5; Sat, 3 May 2008 16:56:39 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTALaRLWIl4V; Sat, 3 May 2008 16:56:39 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id B2CF84806CF; Sat, 3 May 2008 16:56:39 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id BF5C119EC0B9; Sat, 3 May 2008 16:56:38 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1Js9na-00030Q-Lz; Sat, 03 May 2008 16:56:38 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org, phoffman@imc.org Subject: RE: S/MIME v3.2 IDs key size text In-Reply-To: Message-Id: Date: Sat, 03 May 2008 16:56:38 +1200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul Hoffman writes: >At 6:16 AM +1200 5/3/08, Peter Gutmann wrote: >>Aren't these mutually exclusive? > >Yes; that's why they are in separate sections. How does this reconcile them? Do we get to choose which ones we want? >>(The "or shorter" attached to the "1024" is also going to prove problematic >>with FIPS-evaluated crypto implementations, since you can't do < 1024 bits >>for those). > >That's just plain wrong. Nothing in the FIPS evaluation says that you cannot >verify signatures shorter than what they require. I didn't say you couldn't verify sigs, I said you couldn't get the code to do that evaluated because the minimum they'll accept is 1024 bits. In other words you'd be using non-evaluated code (or code run in a non-evaluated mode) to do the sig. verification. Peter. 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 m42MkSOm014051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 15:46:28 -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 m42MkS9c014049; Fri, 2 May 2008 15:46:28 -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 m42MkND6014005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 15:46:25 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 2 May 2008 15:46:21 -0700 To: Luther Martin , "ietf-smime@imc.org" From: Paul Hoffman Subject: RE: S/MIME v3.2 IDs key size text 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 3:17 PM -0700 5/2/08, Luther Martin wrote: > > >(The "or shorter" attached to the "1024" is also going to prove >> problematic >> >with FIPS-evaluated crypto implementations, since you can't do < 1024 >> bits for >> >those). >> >> That's just plain wrong. Nothing in the FIPS evaluation says that you >> cannot verify signatures shorter than what they require. > >I'm not sure that's accurate. A FIPS security policy is fairly clear >about exactly what keys and key sizes you can use in FIPS mode, and >I'm fairly sure that this stops you from using smaller keys in FIPS >mode, even to verify a signature. That's quite different than what I said. In FIPS mode, you may need to only validate FIPS-mandated signatures (there is even some disagreement about this). However, a FIPS-evaluated system can also validate non-FIPS-mandated signatures, just not in FIPS mode (maybe). 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 m42MHjan002023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 15:17: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 m42MHjIK002022; Fri, 2 May 2008 15:17: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.voltage.com (mail.voltage.com [209.213.222.98]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m42MHibt002008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 15:17:45 -0700 (MST) (envelope-from martin@voltage.com) Received: from hqmailsvr01.voltage.com (hqmailsvr01.voltage.com [172.16.0.22]) by mail.voltage.com (8.13.7/8.13.7) with ESMTP id m42MI5cE020651 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 2 May 2008 15:18:05 -0700 Received: from hqmailsvr01.voltage.com ([172.16.0.22]) by hqmailsvr01.voltage.com ([172.16.0.22]) with mapi; Fri, 2 May 2008 15:17:43 -0700 From: Luther Martin To: "'Paul Hoffman'" , "ietf-smime@imc.org" Date: Fri, 2 May 2008 15:17:43 -0700 Subject: RE: S/MIME v3.2 IDs key size text Thread-Topic: S/MIME v3.2 IDs key size text Thread-Index: AcisoRdLcJxLfqhgQJOqvCo62JIenQAAH5iw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=4.65.7161:2.4.4,1.2.40,4.0.164 definitions=2008-05-02_08:2008-05-02,2008-05-02,2008-05-02 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=1 spamscore=1 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=3.1.0-0804140000 definitions=main-0805020158 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > >(The "or shorter" attached to the "1024" is also going to prove > problematic > >with FIPS-evaluated crypto implementations, since you can't do < 1024 > bits for > >those). > > That's just plain wrong. Nothing in the FIPS evaluation says that you > cannot verify signatures shorter than what they require. I'm not sure that's accurate. A FIPS security policy is fairly clear about = exactly what keys and key sizes you can use in FIPS mode, and I'm fairly su= re that this stops you from using smaller keys in FIPS mode, even to verify= a signature. 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 m42LhtVa086134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 14:43:55 -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 m42Lht6u086131; Fri, 2 May 2008 14:43:55 -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 m42Lhorp086080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 2 May 2008 14:43:54 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <002701c8ac83$5bc1cd20$02b5a8c0@tony> References: <002701c8ac83$5bc1cd20$02b5a8c0@tony> Date: Fri, 2 May 2008 14:43:30 -0700 To: From: Paul Hoffman Subject: RE: S/MIME v3.2 IDs key size text 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:35 PM -0400 5/2/08, Tony Capel wrote: >I think the minimum supported size needs to be 2048 because: Please be more specific. Supported for what? Signing, verifying, or both? >1) Since at least April 2007 (over a year ago) Verisign has been issuing certs >with 2048 keys (I believe this is selectable when enrolling) >(although the root >cert is only 1024!). >2) NIST is recommending 2048 by end of 2008 for signatures and key >transport for >some apps [SP-800-78-1 Table 3.1]. >3) Many/most hardware tokens (e.g. Safenet, Gem, Aladdin) are supporting 1024 >and 2048 (only). The wording clearly says that you should expect to validate larger keys, which are covered by those three data points. Your last point (hardware tokens signing at 1024) is exactly why I think mandating the ability to sign at least 1024 bits is a good idea. >As far as going larger than 2048, in my brief survey, while there >appears to be >a small level of interest in 3072 (and even 4096), beyond that many >appear to be >recommending a switch to ECC because of the exponentially rising >power/cpu costs >for larger RSA sizes (e.g. NSA Suite B). The current text encourages being able to verify at any level, not just 1024 or even 2048. >So I would suggest making 2048 and smaller mandatory. And using a >sentence like: >" Note that receiving agents may see signatures whose key length is >longer than >2048 > bits in the future, and support for lengths of 3072 and 4078 SHOULD >be provided > > to verify those signatures." I fully disagree. We are talking about interoperability here, not best practice. We should not be mandating that receivers be able to verify things that beyond what is mandated for signers. If you want to change the length of what signers are required to do, that's fine, I would want both sides to be accordance. But until then, saying "you must be able to verify something larger than what you can sign" doesn't make sense from an interoperability standpoint. Also, we should not mandate SHOULD-level requirements for particular size keys. For verification, specific bit-lengths are not important: it is the maximum key length. >Or > > "... for lengths up to and including 4078 SHOULD ..." > >to address optional support. This doesn't seem to be a good reading of RFC 2119. 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 m42LhsNl086111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 14:43:54 -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 m42Lhsj3086110; Fri, 2 May 2008 14:43:54 -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 m42Lhorn086080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 2 May 2008 14:43:53 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 2 May 2008 14:43:47 -0700 To: ietf-smime@imc.org From: Paul Hoffman Subject: RE: S/MIME v3.2 IDs key size text 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 6:16 AM +1200 5/3/08, Peter Gutmann wrote: >"Turner, Sean P." writes: > >>A receiving agent needs to be able to verify signatures whose key length is >>chosen by the signer. For interoperability, a receiving agent MUST be able to >>verify signatures whose key length is 1024 bits or shorter. > >[...] > >>Receiving agents are only required to validate signatures that are the same >>length as sending agents are required to produce, namely 1024 bits. > >Aren't these mutually exclusive? Yes; that's why they are in separate sections. >(The "or shorter" attached to the "1024" is also going to prove problematic >with FIPS-evaluated crypto implementations, since you can't do < 1024 bits for >those). That's just plain wrong. Nothing in the FIPS evaluation says that you cannot verify signatures shorter than what they require. 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 m42Ia00X002138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 11:36:00 -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 m42Ia00d002136; Fri, 2 May 2008 11:36:00 -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 m42IZvr2002115 for ; Fri, 2 May 2008 11:36:00 -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 1Js06v-0002h6-1S; Fri, 02 May 2008 14:35:57 -0400 From: "Tony Capel" To: "'Turner, Sean P.'" , Subject: RE: S/MIME v3.2 IDs key size text Date: Fri, 2 May 2008 14:35:55 -0400 Message-ID: <002701c8ac83$5bc1cd20$02b5a8c0@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 Thread-Index: AciOo6ubmDvRbsL0T2OcCb8+6E2KgQd1rSogAAFe1rA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <008501c8ac7b$6a1e88c0$0201a8c0@Wylie> Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sean: I think the minimum supported size needs to be 2048 because: 1) Since at least April 2007 (over a year ago) Verisign has been issuing = certs with 2048 keys (I believe this is selectable when enrolling) (although = the root cert is only 1024!). 2) NIST is recommending 2048 by end of 2008 for signatures and key = transport for some apps [SP-800-78-1 Table 3.1]. 3) Many/most hardware tokens (e.g. Safenet, Gem, Aladdin) are supporting = 1024 and 2048 (only). As far as going larger than 2048, in my brief survey, while there = appears to be a small level of interest in 3072 (and even 4096), beyond that many = appear to be recommending a switch to ECC because of the exponentially rising = power/cpu costs for larger RSA sizes (e.g. NSA Suite B). So I would suggest making 2048 and smaller mandatory. And using a = sentence like: " Note that receiving agents may see signatures whose key length is = longer than 2048=20 bits in the future, and support for lengths of 3072 and 4078 SHOULD be = provided to verify those signatures." Or "... for lengths up to and including 4078 SHOULD ..." to address optional support. 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: May 2, 2008 1:39 PM | To: ietf-smime@imc.org | Subject: RE: S/MIME v3.2 IDs key size text |=20 |=20 |=20 | Paul has suggest a rewording of his text for 4.1 as follows: |=20 | A receiving agent needs to be able to verify signatures whose=20 | key length is chosen by the signer. For interoperability, a=20 | receiving agent MUST be able to verify signatures whose key=20 | length is 1024 bits or shorter. Being able to verify=20 | signatures is mandatory because earlier versions of this=20 | specification required the ability to generate signatures=20 | with shorter key lengths. Note that most receiving agents are=20 | likely to see signatures whose key length is longer than 1024=20 | bits during the next decade, and those receiving agents will=20 | want to be able to verify those signatures. |=20 | He's also suggested the following security consideration: |=20 | Receiving agents are only required to validate signatures=20 | that are the same length as sending agents are required to=20 | produce, namely 1024 bits. Many people feel that signatures=20 | of 1024 bits do not meet their security requirements today,=20 | or even if they meet their requirements today, they will not=20 | meet their requirements in the foreseeable future. Therefore,=20 | sending and receiving agents need to decide what strength of=20 | signature they want to produce and validate, respectively.=20 | Further, those decisions need to be reviewed periodically in=20 | light of decreasing cryptographic strength over time of signatures. |=20 | spt |=20 | >-----Original Message----- | >From: Paul Hoffman [mailto:phoffman@imc.org] | >Sent: Tuesday, March 25, 2008 2:12 PM | >To: Turner, Sean P.; 'Russ Housley'; ietf-smime@imc.org | >Subject: RE: S/MIME v3.2 IDs key size text | > | >At 10:16 AM -0400 3/25/08, Turner, Sean P. wrote: | >>This sounds reasonable. I replace the following sentence in 3851bis: | >> | >>A receiving agent SHOULD be able to verify signatures with | >keys of any | >>size over 512 bits. | >> | >>with | >> | >>A receiving agent SHOULD be able to verify signatures with=20 | keys up to | >>16384 bits. | > | >I disagree with the upper limit. Verifying signatures with 16K | >bit keys is very difficult for constrained devices; this=20 | >"SHOULD" may have the effect of making device makers need to=20 | >use faster CPUs than they would normally want to have. | > | >It is unclear which part of the SHOULD is not a MUST here. | >Because we are talking only about interoperability, then the=20 | >number is 1024, which is what the key creators SHOULD be=20 | >making. But that is clearly a lower bound of what a typical=20 | >receiver might expect. Therefore, a short sentence like the=20 | >one proposed is insufficient. How about: | > | >A receiving agent needs to be able to verify signatures whose | >key length is chosen by the signer. At a minimum, a receiving=20 | >agent MUST be able to verify signatures whose key length is=20 | >1024 bits or shorter. However, most receiving agents are=20 | >likely to see signatures whose key length is longer than that=20 | >during the next decade. |=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 m42IGSJs093793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 11:16:28 -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 m42IGSmb093791; Fri, 2 May 2008 11:16:28 -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 mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m42IGQ98093775 for ; Fri, 2 May 2008 11:16:27 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 1665418827; Sat, 3 May 2008 06:16:26 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHWyRL8SxogE; Sat, 3 May 2008 06:16:25 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 5CCDC18823; Sat, 3 May 2008 06:16:24 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id EEEBC19EC0B9; Sat, 3 May 2008 06:16:23 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1Jrznz-0005zT-Rs; Sat, 03 May 2008 06:16:23 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org, turners@ieca.com Subject: RE: S/MIME v3.2 IDs key size text In-Reply-To: <008501c8ac7b$6a1e88c0$0201a8c0@Wylie> Message-Id: Date: Sat, 03 May 2008 06:16:23 +1200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Turner, Sean P." writes: >A receiving agent needs to be able to verify signatures whose key length is >chosen by the signer. For interoperability, a receiving agent MUST be able to >verify signatures whose key length is 1024 bits or shorter. [...] >Receiving agents are only required to validate signatures that are the same >length as sending agents are required to produce, namely 1024 bits. Aren't these mutually exclusive? (The "or shorter" attached to the "1024" is also going to prove problematic with FIPS-evaluated crypto implementations, since you can't do < 1024 bits for those). Peter. 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 m42HjXct079652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 10:45: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 m42HjXYh079651; Fri, 2 May 2008 10:45: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 mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m42HjWxQ079635 for ; Fri, 2 May 2008 10:45:33 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 8A49628C362; Fri, 2 May 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-rfc3278-update-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080502174502.8A49628C362@core3.amsl.com> Date: Fri, 2 May 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 : Update to Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) Author(s) : S. Turner Filename : draft-ietf-smime-rfc3278-update-03.txt Pages : 28 Date : 2008-5-2 RFC 3278 describes how to use Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic Message Syntax (CMS). This document updates RFC 3278 to add support for the SHA2 family of hash algorithms, Elliptic Curve Digital Signature Algorithm (ECDSA) 224-512, and Key Derivation Functions (KDFs) that utilize SHA2 algorithms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc3278-update-03.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-rfc3278-update-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-5-2104433.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 m42Hh0kQ078607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 10:43:00 -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 m42Hh0oD078606; Fri, 2 May 2008 10:43:00 -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 smtp105.biz.mail.re2.yahoo.com (smtp105.biz.mail.re2.yahoo.com [206.190.52.174]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m42HgxJA078597 for ; Fri, 2 May 2008 10:43:00 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 97220 invoked from network); 2 May 2008 17:42:53 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@71.191.1.177 with login) by smtp105.biz.mail.re2.yahoo.com with SMTP; 2 May 2008 17:42:53 -0000 X-YMail-OSG: KCw.VrkVM1kFU_LJO7TZfMeOeFlVXU73Zj1QggsD7CfnuVQ2XE75iGoCBLLGf9fQo4fP2PLFpysGp.AjOj6WUptmT1mkINcIYysOZuMQtMgEvknVGRWrM.OdRubC0nUHaBU- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: References: <019501c889f4$8185e340$0301a8c0@Wylie> <200803192107.m2JL7PYY060318@balder-227.proper.com> <00b401c88e82$d983df10$0301a8c0@Wylie> Subject: RE: S/MIME v3.2 IDs key size text Date: Fri, 2 May 2008 13:39:03 -0400 Organization: IECA, Inc. Message-ID: <008501c8ac7b$6a1e88c0$0201a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciOo6ubmDvRbsL0T2OcCb8+6E2KgQd1rSog X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul has suggest a rewording of his text for 4.1 as follows: A receiving agent needs to be able to verify signatures whose key length is chosen by the signer. For interoperability, a receiving agent MUST be able to verify signatures whose key length is 1024 bits or shorter. Being able to verify signatures is mandatory because earlier versions of this specification required the ability to generate signatures with shorter key lengths. Note that most receiving agents are likely to see signatures whose key length is longer than 1024 bits during the next decade, and those receiving agents will want to be able to verify those signatures. He's also suggested the following security consideration: Receiving agents are only required to validate signatures that are the same length as sending agents are required to produce, namely 1024 bits. Many people feel that signatures of 1024 bits do not meet their security requirements today, or even if they meet their requirements today, they will not meet their requirements in the foreseeable future. Therefore, sending and receiving agents need to decide what strength of signature they want to produce and validate, respectively. Further, those decisions need to be reviewed periodically in light of decreasing cryptographic strength over time of signatures. spt >-----Original Message----- >From: Paul Hoffman [mailto:phoffman@imc.org] >Sent: Tuesday, March 25, 2008 2:12 PM >To: Turner, Sean P.; 'Russ Housley'; ietf-smime@imc.org >Subject: RE: S/MIME v3.2 IDs key size text > >At 10:16 AM -0400 3/25/08, Turner, Sean P. wrote: >>This sounds reasonable. I replace the following sentence in 3851bis: >> >>A receiving agent SHOULD be able to verify signatures with >keys of any >>size over 512 bits. >> >>with >> >>A receiving agent SHOULD be able to verify signatures with keys up to >>16384 bits. > >I disagree with the upper limit. Verifying signatures with 16K >bit keys is very difficult for constrained devices; this >"SHOULD" may have the effect of making device makers need to >use faster CPUs than they would normally want to have. > >It is unclear which part of the SHOULD is not a MUST here. >Because we are talking only about interoperability, then the >number is 1024, which is what the key creators SHOULD be >making. But that is clearly a lower bound of what a typical >receiver might expect. Therefore, a short sentence like the >one proposed is insufficient. How about: > >A receiving agent needs to be able to verify signatures whose >key length is chosen by the signer. At a minimum, a receiving >agent MUST be able to verify signatures whose key length is >1024 bits or shorter. However, most receiving agents are >likely to see signatures whose key length is longer than that >during the next decade.