From apache@server.aprilvpshost.net Sat Nov 1 20:18:08 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4C1E3A67B6 for ; Sat, 1 Nov 2008 20:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.894 X-Spam-Level: X-Spam-Status: No, score=-92.894 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_50=0.001, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, SUBJ_ALL_CAPS=2.077, 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 MshLkGl7gOKu for ; Sat, 1 Nov 2008 20:18:08 -0700 (PDT) Received: from server.aprilvpshost.net (giat-bekerja.sabar.berdoa.agar.sukses2u.com [72.20.24.115]) by core3.amsl.com (Postfix) with ESMTP id 0AB1E3A6821 for ; Sat, 1 Nov 2008 20:18:08 -0700 (PDT) Received: from apache by server.aprilvpshost.net with local (Exim 4.67) (envelope-from ) id 1KwRnu-0003bK-Me for smime-archive@ietf.org; Sat, 01 Nov 2008 20:30:58 -0500 To: smime-archive@ietf.org Subject: RESPOND IMMEDIATELY - REGARDING YOUR SME GRANT X-PHP-Script: 72.20.24.115/~april/mailers/3/index.php for 216.139.189.105 From: European Commission Reply-To: dominic.brett@live.co.uk MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: 8bit Message-Id: Date: Sat, 01 Nov 2008 20:30:58 -0500 New Page 1

European Commission
Enterprise and Industry DG
Communication and Information Unit/R4
BREY 13/ 092
B - 1049 Brussels (Belgium)

Released: October 2008.

We bring to your notice the decision by the board of trustees of The European Union to choose you as one of the final recipients of a cash grant/donation for your own personal, educational, and business development (SME funding).

To promote growth and creating new jobs in the European economy, we are giving out a yearly donation of £402,000.00 (four hundred and two thousand pounds) to 10 lucky recipients who have been selected from over 25,000 websites all over the globe, as funding/aid from the European Union, European Commission, and the United Nations in accordance with enabling acts of Parliament.

Please contact paying office (England)

Name: Dr. Dominic Brett
E-mail: dominic.brett@live.co.uk

Remember to quote your identification numbers. Find your identification numbers below:

BATCH NUMBER: EC-078419XN
UNIQUE NUMBER: SME48153


Note that these numbers fall within your location file.

Thank you and accept my congratulations once again!

Janet Williamson
Information Officer and Coordinator,
Scottish European Resources Network


========
+++++CONFIDENTIALITY NOTICE+++++
the information in this e-mail may be confidential and/or privileged. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination or copying of this e-mail and its attachments, if any, or the information contained herein is prohibited. If you have received this e-mail in error, please immediately notify the sender by return e-mail and delete this e-mail from your computer system. Thank you.

From apache@server.aprilvpshost.net Sat Nov 1 23:12: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 4A5903A688D for ; Sat, 1 Nov 2008 23:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.905 X-Spam-Level: X-Spam-Status: No, score=-92.905 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_50=0.001, DATE_IN_PAST_03_06=0.044, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, SUBJ_ALL_CAPS=2.077, 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 jnXUykGhL3AS for ; Sat, 1 Nov 2008 23:12:50 -0700 (PDT) Received: from server.aprilvpshost.net (giat-bekerja.sabar.berdoa.agar.sukses2u.com [72.20.24.115]) by core3.amsl.com (Postfix) with ESMTP id 5013D3A6856 for ; Sat, 1 Nov 2008 23:12:45 -0700 (PDT) Received: from apache by server.aprilvpshost.net with local (Exim 4.67) (envelope-from ) id 1KwRnu-0003bM-Nj for smime-archive@lists.ietf.org; Sat, 01 Nov 2008 20:30:58 -0500 To: smime-archive@lists.ietf.org Subject: RESPOND IMMEDIATELY - REGARDING YOUR SME GRANT X-PHP-Script: 72.20.24.115/~april/mailers/3/index.php for 216.139.189.105 From: European Commission Reply-To: dominic.brett@live.co.uk MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: 8bit Message-Id: Date: Sat, 01 Nov 2008 20:30:58 -0500 New Page 1

European Commission
Enterprise and Industry DG
Communication and Information Unit/R4
BREY 13/ 092
B - 1049 Brussels (Belgium)

Released: October 2008.

We bring to your notice the decision by the board of trustees of The European Union to choose you as one of the final recipients of a cash grant/donation for your own personal, educational, and business development (SME funding).

To promote growth and creating new jobs in the European economy, we are giving out a yearly donation of £402,000.00 (four hundred and two thousand pounds) to 10 lucky recipients who have been selected from over 25,000 websites all over the globe, as funding/aid from the European Union, European Commission, and the United Nations in accordance with enabling acts of Parliament.

Please contact paying office (England)

Name: Dr. Dominic Brett
E-mail: dominic.brett@live.co.uk

Remember to quote your identification numbers. Find your identification numbers below:

BATCH NUMBER: EC-078419XN
UNIQUE NUMBER: SME48153


Note that these numbers fall within your location file.

Thank you and accept my congratulations once again!

Janet Williamson
Information Officer and Coordinator,
Scottish European Resources Network


========
+++++CONFIDENTIALITY NOTICE+++++
the information in this e-mail may be confidential and/or privileged. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination or copying of this e-mail and its attachments, if any, or the information contained herein is prohibited. If you have received this e-mail in error, please immediately notify the sender by return e-mail and delete this e-mail from your computer system. Thank you.

From apache@server.aprilvpshost.net Sun Nov 2 00:07: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 40F203A682C for ; Sun, 2 Nov 2008 00:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.919 X-Spam-Level: X-Spam-Status: No, score=-92.919 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_50=0.001, DATE_IN_PAST_03_06=0.044, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, SUBJ_ALL_CAPS=2.077, 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 aVS9CZ560NSY for ; Sun, 2 Nov 2008 00:07:29 -0700 (PDT) Received: from server.aprilvpshost.net (giat-bekerja.sabar.berdoa.agar.sukses2u.com [72.20.24.115]) by core3.amsl.com (Postfix) with ESMTP id E59553A67FB for ; Sun, 2 Nov 2008 00:07:28 -0700 (PDT) Received: from apache by server.aprilvpshost.net with local (Exim 4.67) (envelope-from ) id 1KwRnu-0003bO-PN for smime-archive@megatron.ietf.org; Sat, 01 Nov 2008 20:30:58 -0500 To: smime-archive@megatron.ietf.org Subject: RESPOND IMMEDIATELY - REGARDING YOUR SME GRANT X-PHP-Script: 72.20.24.115/~april/mailers/3/index.php for 216.139.189.105 From: European Commission Reply-To: dominic.brett@live.co.uk MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: 8bit Message-Id: Date: Sat, 01 Nov 2008 20:30:58 -0500 New Page 1

European Commission
Enterprise and Industry DG
Communication and Information Unit/R4
BREY 13/ 092
B - 1049 Brussels (Belgium)

Released: October 2008.

We bring to your notice the decision by the board of trustees of The European Union to choose you as one of the final recipients of a cash grant/donation for your own personal, educational, and business development (SME funding).

To promote growth and creating new jobs in the European economy, we are giving out a yearly donation of £402,000.00 (four hundred and two thousand pounds) to 10 lucky recipients who have been selected from over 25,000 websites all over the globe, as funding/aid from the European Union, European Commission, and the United Nations in accordance with enabling acts of Parliament.

Please contact paying office (England)

Name: Dr. Dominic Brett
E-mail: dominic.brett@live.co.uk

Remember to quote your identification numbers. Find your identification numbers below:

BATCH NUMBER: EC-078419XN
UNIQUE NUMBER: SME48153


Note that these numbers fall within your location file.

Thank you and accept my congratulations once again!

Janet Williamson
Information Officer and Coordinator,
Scottish European Resources Network


========
+++++CONFIDENTIALITY NOTICE+++++
the information in this e-mail may be confidential and/or privileged. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination or copying of this e-mail and its attachments, if any, or the information contained herein is prohibited. If you have received this e-mail in error, please immediately notify the sender by return e-mail and delete this e-mail from your computer system. Thank you.

From owner-ietf-smime@mail.imc.org Mon Nov 3 16:47: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 EEFA728C499 for ; Mon, 3 Nov 2008 16:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.908 X-Spam-Level: X-Spam-Status: No, score=-100.908 tagged_above=-999 required=5 tests=[AWL=-1.123, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, MSGID_FROM_MTA_HEADER=0.803, 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 fSCTFRrvpqmR for ; Mon, 3 Nov 2008 16:47:22 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 5F7E428C47E for ; Mon, 3 Nov 2008 16:46:16 -0800 (PST) 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 mA3NSWRU009118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Nov 2008 16:28: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 mA3NSWEs009117; Mon, 3 Nov 2008 16:28: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 woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mA3NSLQO009097 for ; Mon, 3 Nov 2008 16:28:32 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200811032328.mA3NSLQO009097@balder-227.proper.com> Received: (qmail 12059 invoked by uid 0); 3 Nov 2008 23:28:13 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 3 Nov 2008 23:28:13 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 03 Nov 2008 18:21:25 -0500 To: zhaohui cheng From: Russ Housley Subject: Re: Consistence question of CMS Cc: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think this is an error.  I think the end of the RFC 3852 algorithm should be:

               IF (originatorInfo is absent) AND
                  (unprotectedAttrs is absent) AND
                  (all RecipientInfo structures are version 0)
               THEN version is 0
               ELSE version is 2

Do others agree?

Russ


At 01:04 AM 11/3/2008, zhaohui cheng wrote:

Hi Russell,

I have a question regarding the consistence between RFC 3852 and RFC 3369.

For the version of EnvelopedData, the rules in RFC 3369 and  RFC 3852  are defined as follows

 ---RFC 3369

         IF ((originatorInfo is present) AND
             (any version 2 attribute certificates are present)) OR
            (any RecipientInfo structures include pwri) OR
            (any RecipientInfo structures include ori)
         THEN version is 3
         ELSE
            IF (originatorInfo is present) OR
               (unprotectedAttrs is present) OR
               (any RecipientInfo structures are a version other than 0)
            THEN version is 2
            ELSE version is 0

 

--RFC 3852 
         IF (originatorInfo is present) AND
            ((any certificates with a type of other are present) OR
            (any crls with a type of other are present))
         THEN version is 4
         ELSE
            IF ((originatorInfo is present) AND
               (any version 2 attribute certificates are present)) OR
               (any RecipientInfo structures include pwri) OR
               (any RecipientInfo structures include ori)
            THEN version is 3
            ELSE
               IF (originatorInfo is absent) OR
                  (unprotectedAttrs is absent) OR
                  (all RecipientInfo structures are version 0)
               THEN version is 0
               ELSE version is 2

It appears the two sets of rules are not consistent.  In particular, if originatorInfo is absent but one

RecipientInfo structure has version other than 0, then according to RFC 3369, the version should be 2, but 0 in 3852. Is this rule deliberately changed in 3852 or just typos?

Kind regards,

Michael Cheng
From owner-ietf-smime@mail.imc.org Wed Nov 5 09:24: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 AFDBB3A69EA for ; Wed, 5 Nov 2008 09:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.852 X-Spam-Level: * X-Spam-Status: No, score=1.852 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_MISMATCH_COM=0.553, 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 WOtct-f25U3u for ; Wed, 5 Nov 2008 09:24:10 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id C0F473A6998 for ; Wed, 5 Nov 2008 09:24:10 -0800 (PST) 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 mA5H9YbW007016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Nov 2008 10:09: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 mA5H9YL2007015; Wed, 5 Nov 2008 10:09: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 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 mA5H9LpT007000 for ; Wed, 5 Nov 2008 10:09:33 -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 AA104314877; Wed, 5 Nov 2008 18:07:57 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id SAA01398; Wed, 5 Nov 2008 18:07:56 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200811051707.SAA01398@TR-Sys.de> Subject: Re: [ietf-smime] Consistence question of CMS To: housley@vigilsec.com Date: Wed, 5 Nov 2008 18:07:55 +0100 (MEZ) Cc: ietf-smime@imc.org 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: At Mon, 03 Nov 2008 18:21:25 -0500 , Russ Housley wrote: > I think this is an error. > I think the end of the RFC 3852 algorithm should be: > > IF (originatorInfo is absent) AND > (unprotectedAttrs is absent) AND > (all RecipientInfo structures are version 0) > THEN version is 0 > ELSE version is 2 > > Do others agree? > > Russ Yes. I agree. But that's by far an easy job, more of re-inventing the wheel: Looking up my printed copy of RFC 3852, I found a bold question mark on page 18, vis-a-vis of that algorithm, and an exclamation mark pointing out the diff from 3369. Sigh -- admittedly I had to recognize that apparently I never had found the time to report errata for that RFC ... :-) But *you* did, Russ! ( on 2005-01-22 ) Folks, please look up the result of Russ' error report at: 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 | +------------------------+--------------------------------------------+ From owner-ietf-smime@mail.imc.org Wed Nov 5 09:54: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 83D6D3A67D8 for ; Wed, 5 Nov 2008 09:54:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[AWL=-1.021, BAYES_05=-1.11, 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 vs-ZOkg0y-+p for ; Wed, 5 Nov 2008 09:54:53 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 85F5D3A69E4 for ; Wed, 5 Nov 2008 09:54:53 -0800 (PST) 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 mA5HgmKH009518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Nov 2008 10:42: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 mA5HgmLj009517; Wed, 5 Nov 2008 10:42: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 smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mA5HgbjL009488 for ; Wed, 5 Nov 2008 10:42:47 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 49195 invoked from network); 5 Nov 2008 17:42:37 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@71.191.15.124 with login) by smtp104.biz.mail.re2.yahoo.com with SMTP; 5 Nov 2008 17:42:36 -0000 X-YMail-OSG: ZlNf8fgVM1kIUIXL_Y5Nl_Es3DJj.QL2hut3yKBzsVjqS3wmJHM1lbd97WWgRi23L2IOL4LhX0X2cp7wqZ9KZ4qpsbs0s_PIcIXh81YhTy20WPccCLcjTdW7setHulqaPaFVYD6Vbj_MTo1EAwoxLgRh8cr5vrRzH2RAXxcz5EEoaw7YnwlLoUG4oPXNtg-- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "'Russ Housley'" , "'zhaohui cheng'" Cc: References: <200811032328.mA3NSLQO009097@balder-227.proper.com> Subject: RE: Consistence question of CMS Date: Wed, 5 Nov 2008 12:42:25 -0500 Organization: IECA, Inc. Message-ID: <05F0571B98CF4ACC861A55AA8CCE452D@Wylie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D9_01C93F43.F5064F80" X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ack+Fo/TgP3es6qFSN6IK6My4PgIjQBVwi5Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <200811032328.mA3NSLQO009097@balder-227.proper.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_00D9_01C93F43.F5064F80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Russ, Yes - I agree. RFC 2630 also supports this: If originatorInfo is absent, all of the RecipientInfo structures are version 0, and unprotectedAttrs is absent, then version shall be 0. Also originatorInfo and unprotectedAttributes aren't defined in RFC 2315 so to be version 0 these fields can't be present. To be version 0, RecipientInfos must also have a version = -0, according to RFC 3215. spt _____ From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Russ Housley Sent: Monday, November 03, 2008 6:21 PM To: zhaohui cheng Cc: ietf-smime@imc.org Subject: Re: Consistence question of CMS I think this is an error. I think the end of the RFC 3852 algorithm should be: IF (originatorInfo is absent) AND (unprotectedAttrs is absent) AND (all RecipientInfo structures are version 0) THEN version is 0 ELSE version is 2 Do others agree? Russ At 01:04 AM 11/3/2008, zhaohui cheng wrote: Hi Russell, I have a question regarding the consistence between RFC 3852 and RFC 3369. For the version of EnvelopedData, the rules in RFC 3369 and RFC 3852 are defined as follows ---RFC 3369 IF ((originatorInfo is present) AND (any version 2 attribute certificates are present)) OR (any RecipientInfo structures include pwri) OR (any RecipientInfo structures include ori) THEN version is 3 ELSE IF (originatorInfo is present) OR (unprotectedAttrs is present) OR (any RecipientInfo structures are a version other than 0) THEN version is 2 ELSE version is 0 --RFC 3852 IF (originatorInfo is present) AND ((any certificates with a type of other are present) OR (any crls with a type of other are present)) THEN version is 4 ELSE IF ((originatorInfo is present) AND (any version 2 attribute certificates are present)) OR (any RecipientInfo structures include pwri) OR (any RecipientInfo structures include ori) THEN version is 3 ELSE IF (originatorInfo is absent) OR (unprotectedAttrs is absent) OR (all RecipientInfo structures are version 0) THEN version is 0 ELSE version is 2 It appears the two sets of rules are not consistent. In particular, if originatorInfo is absent but one RecipientInfo structure has version other than 0, then according to RFC 3369, the version should be 2, but 0 in 3852. Is this rule deliberately changed in 3852 or just typos? Kind regards, Michael Cheng ------=_NextPart_000_00D9_01C93F43.F5064F80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Russ,

Yes - I agree. RFC 2630 also supports this:

If originatorInfo is absent, all of the RecipientInfo structures are = version=20 0, and unprotectedAttrs is absent, then version shall be 0.

Also originatorInfo and unprotectedAttributes aren't defined in RFC = 2315 so=20 to be version 0 these fields can't be present. To be version 0, = RecipientInfos=20 must also have a version =3D -0, according to RFC 3215.

spt



From: = owner-ietf-smime@mail.imc.org=20 [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Russ=20 Housley
Sent: Monday, November 03, 2008 6:21 = PM
To:=20 zhaohui cheng
Cc: ietf-smime@imc.org
Subject: Re:=20 Consistence question of CMS

I think this is an error.  I think the end of the RFC = 3852=20 algorithm should=20 = be:

          &n= bsp;   =20 IF (originatorInfo is absent)=20 = AND
           =       =20 (unprotectedAttrs is absent)=20 = AND
           =       =20 (all RecipientInfo structures are version=20 = 0)
           &= nbsp;  =20 THEN version is=20 = 0
           &n= bsp;  =20 ELSE version is 2

Do others agree?

Russ


At = 01:04 AM=20 11/3/2008, zhaohui cheng wrote:

Hi Russell,

I have a question = regarding=20 the consistence between RFC 3852 and RFC 3369.

For the = version of=20 EnvelopedData, the rules in RFC 3369 and  RFC 3852  are = defined as=20 follows

 ---RFC=20 3369

         IF=20 ((originatorInfo is present)=20 = AND
           =  =20 (any version 2 attribute certificates are present))=20 = OR
            = (any RecipientInfo structures include pwri)=20 = OR
            = (any RecipientInfo structures include=20 ori)
         THEN = version is=20 3
        =20 = ELSE
           = ;=20 IF (originatorInfo is present)=20 = OR
           &= nbsp;  =20 (unprotectedAttrs is present)=20 = OR
           &= nbsp;  =20 (any RecipientInfo structures are a version other than=20 = 0)
            = THEN version is=20 = 2
            = ELSE=20 version is 0

 

--RFC 3852 =20
         IF = (originatorInfo is=20 present)=20 = AND
           = =20 ((any certificates with a type of other are present)=20 = OR
            = (any crls with a type of other are=20 present))
         THEN = version=20 is 4
        =20 = ELSE
           = ;=20 IF ((originatorInfo is present)=20 = AND
           =    =20 (any version 2 attribute certificates are present))=20 = OR
           &= nbsp;  =20 (any RecipientInfo structures include pwri)=20 = OR
           &= nbsp;  =20 (any RecipientInfo structures include=20 = ori)
           = ;=20 THEN version is=20 = 3
           =20 = ELSE
           = ;   =20 IF (originatorInfo is absent)=20 = OR
           &= nbsp;     =20 (unprotectedAttrs is absent)=20 = OR
           &= nbsp;     =20 (all RecipientInfo structures are version=20 = 0)
           &= nbsp;  =20 THEN version is=20 = 0
           &n= bsp;  =20 ELSE version is 2

It appears the two sets of rules are not=20 consistent.  In particular, if originatorInfo is absent but one =

RecipientInfo structure has version other than 0, then = according to=20 RFC 3369, the version should be 2, but 0 in 3852. Is this rule = deliberately=20 changed in 3852 or just typos?

Kind regards,

Michael=20 Cheng
------=_NextPart_000_00D9_01C93F43.F5064F80-- From owner-ietf-smime@mail.imc.org Thu Nov 6 05:21: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 A91BA3A6906 for ; Thu, 6 Nov 2008 05:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.744 X-Spam-Level: X-Spam-Status: No, score=-1.744 tagged_above=-999 required=5 tests=[AWL=-0.345, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, J_CHICKENPOX_47=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 cLxBEQi0ibqA for ; Thu, 6 Nov 2008 05:21:37 -0800 (PST) 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 C8BF93A686A for ; Thu, 6 Nov 2008 05:21:36 -0800 (PST) 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 mA6D85H6090765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 06:08:05 -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 mA6D85do090764; Thu, 6 Nov 2008 06:08: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 smtp108.biz.mail.re2.yahoo.com (smtp108.biz.mail.re2.yahoo.com [206.190.52.47]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mA6D7s3u090749 for ; Thu, 6 Nov 2008 06:08:04 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 29425 invoked from network); 6 Nov 2008 13:07:53 -0000 Received: from unknown (HELO Wylie) (turners@71.191.15.124 with login) by smtp108.biz.mail.re2.yahoo.com with SMTP; 6 Nov 2008 13:07:53 -0000 X-YMail-OSG: c_ifIaYVM1mQZHPlVy9deWzcUE.p88Kjt_eTg70KyOt8vK3JqR.Syw2l5_y2IeU6sHRp8QmEJMWvWFiyU2iJt3Vx.GUaXRSgyLOtxon5eDysu0MV3Gwxjcneb2_rdCZPXAuO X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: Subject: RE: WG Last Call: draft-ietf-smime-3278bis-03 Date: Thu, 6 Nov 2008 08:07:39 -0500 Organization: IECA, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: Ack0ivxP1a3c739GTlK9ds19310tKgKLYDUwAADPIcAAAABkgA== Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The WG LC closes today. Below is a list of comments I've received so far. ------- Section 3.1 (E-S ECDH), in the third paragraph, it states that the originatorInfo field MAY include the certificate(s) for the EC public key(s) used in the formation of the pairwise key. The originatorInfo field only contain certs and CRLs related to the originator (and not the recipient). With ephemeral-static, the originaltor does not have a certified public key. spt> I deleted the last two sentences from the paragraph. Section 3.1.1 says that the permitted digest algorithms for use with ECDH were expanded to SHA-1, SHA-224 etc. Note that this is not described in 3.1.1 (which deals with enveloped data). Also, "NULL to absent or ECPoint" should be "NULL to absent or ECParameters". spt> I moved the discussion about the algorithm changes to the bullet describing the Section 5 changes. That line should refer to the hash algorithm used in the KDF and then it would apply to EnvelopedData. In that same area (comments for section 3.1.1) the last word is ECPoint. Shouldn't this be ECParameters? spt> Yes in Section 1.2 the bullet for 3.1.1 should refer to ECParameters not ECPoint. Section 3.1.1 the section on keyEncryption Algorithm says that it must contain the "key encryption algorithm" object identifier (see section 7.1). Section 7.1 does not include anything with that designator. spt> This actually made me go and make sure all the pointers to 7.1 to make sure they pointed to the new sub-sections. It should point to 7.1.4 which is the key agreement information section. I change the 1st sentence to say "keyEncryptionAlgorithm MUST contain the key encryption algorithm, which in this case is a key agreement algorithm, object identifier (see Section 7.1.4)." I also added a pointer to 7.1.5 in the sentence that describes the KeyWrapAlgorithm field. Section 3.1.2 at the end "a shared secret bit string 'K' which is used as the pairwise key-encryption key" is misleading. The shared secret is not the KEK. The shared secret is sent with other info through a KDF to form the KEK. This sentence is replicated in other places in this draft, for example, Section 3.1.3, section 3.2.2, 3.2.3. spt> The key deployment and key agreement operations result in the ephemeral and shared secret. The "Z", which is used to derive the "K", is generated during the key agreement operation. In NIST SP800-56A it's Section 6.2.2 Step 4 (same is true of SEC1 process). Section 3.2.2 - last paragraph talking about multiple layers. You have one message with one recipient and nested layers (eg, encrypted signed encrypted message). This says that you can use the same originator ephemeral key for all of these nested layers? If so, don't you have to ensure that an addedukm field is added at each layer and they are different or does it not matter if you have the same KEK at each layer? Further, NIST SP800-56A says "Each call to the KDF requires a freshly computed shared secret, and this shared secret shall be zeroized imediately following its use". So doesn't that mean you need a new ephmeral for each layer? spt> I'll address this in a seperate email. Section 3.2.3 "....checks that the domain parameters are the same as the recipient's domain parameters" Should recipient be originator instead? spt> I modified the sentence as follows so it's clear the recipient is check that the originator's and recipient's domain parameters are the same: "The receiving agent then retrieves the static and ephemeral EC public keys of the originator, from the originator and ukm fields as described in Section 3.2.1, and its static EC public key identified in the rid field and checks that the ***originator's*** domain parameters are the same as the recipient's domain parameters." Section 4.2 "originatorInfo field MAY include the cert(s) for the EC public key(s)" If originatorInfo only applies to the originator and this is C(1,2, ECC MQV) then don't we have just one static key (ie, you would state EC public key -- not plural) spt> I'll remove the "s". Section 5: "The 1st paragraph was modified to require both SignedData...." Should this be recommend? Also, this comment is for Section 6 not section 5. spt> I changed it to recommended and I merge the two bullets. Section 6: talks about ecdsa-with-SHA* having NULL parameters (to be consistent with RFC3278, section 7). However, this seems to contradict 3851bis, section 2.5.2 , last paragraph. Same thing in the Note in section 6. spt> Yes I ought to change these. I changed the note so that it only applies to SHA-1 and changed NULL to absent in the two ASN.1 modules. Comments for Section 7.1 Should you include "key wrap" in the part about adding subsections? spt> Added it in Section 1.2. Section 7.2 last para listing the KDF in SP800-56A. This KDF is dramatically different from the one in RFC3278. The "otherinfo" in SP800-56A is much more complex and I don't know what values the AlgorithmId, PartyUInfo, PartyVInfo would take by reading this draft. Also, this one does hash(counter || Z || otherinfo); the old kdf did hash(Z || counter || otherinfo) spt> I will address this is in a separate email. Reference: FIPS 180-3 is no longer a draft - it's official as of October 2008. spt> Fixed. Section E.8 of X9.62 says that CMS SignedData represents signatures as a bit string. Section 2.1.1 says "signature MUST contain the DER encoding (as an octet string) " These two are in conflict, but I think that Section 2.1.1 is correct. spt> Glad we got it right ;) Any chance somebody can take this to ANSI? TYPOS Section 1.2 change FIPP to FIPS Section 1.2 -- Section 5. Need an "in" in this sentence: "...to be present in certificates". Section 3 : need a "to" in "security due to the originator's" section 7.1.2: last para. need a " ' " in recipient's ECParameters. section 7.1.3: need to make field plural in first sentence section 7.2: should there be a "." in ephemeralPublicKey.publicKey (wasn't sure) section 8: need to change RECOMMEND to RECOMMENDED Section 9: need to make random number plural spt> all fixed except 7.2 where we left the period. A subfield of originatorPublicKey is publicKey and that's where the key goes. From owner-ietf-smime@mail.imc.org Thu Nov 6 05:22: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 F3B053A6979 for ; Thu, 6 Nov 2008 05:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.675 X-Spam-Level: X-Spam-Status: No, score=-1.675 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, J_CHICKENPOX_47=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 i1-4cJeVzUVF for ; Thu, 6 Nov 2008 05:22:23 -0800 (PST) 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 852AF3A6906 for ; Thu, 6 Nov 2008 05:22:22 -0800 (PST) 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 mA6DB38l091026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 06:11: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 mA6DB3GQ091025; Thu, 6 Nov 2008 06:11: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 smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mA6DApJU090996 for ; Thu, 6 Nov 2008 06:11:02 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 60068 invoked from network); 6 Nov 2008 13:10:51 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@71.191.15.124 with login) by smtp104.biz.mail.re2.yahoo.com with SMTP; 6 Nov 2008 13:10:51 -0000 X-YMail-OSG: d9ov4K0VM1mGlBULmGjbYMWhW1X5_w4Q7PTaD_j1LinDKFtrc23HKJRKlVTFbwWpt5vlhnqcOfa4OTa2Sx3BvBlbLnfQWYJ3RH8hStZNuG2J0TjvbebX2MFOj_KERsZXVXJs X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: Subject: draft-ietf-smime-3278bis: KDF Date: Thu, 6 Nov 2008 08:10:38 -0500 Organization: IECA, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AclAEQ/wwMnEveNoRf2rlFDnakqJLA== Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: One of the comments raised during WG LC noted the difference between the RFC 3278 and NIST SP800-56A KDFs. RFC 3278 was hash(Z || counter || otherinfo) and SP800-56A is hash(counter || Z || otherinfo). I think we need to maintain backwards compatibility and *not* use the NIST SP800-56A KDF and revert back to the KDF used in RFC 3278. Do others agree/disagree? If we revert back, we'd make the following changes: #1 - the last two paragraphs in Section 7.2 will refer to Section 3.6.1 of [SEC1] instead of 6.3.2 of [SP800-56A]. I don't want people to miss this so... #2 - We should amend the two sentences in 3.1.2 and 3.1.3 to say: The sending/receiving agent performs the key agreement operation of the Elliptic Curve Diffie-Hellman Scheme specified in [SP800-56A] or [SEC1]; in either case, use the KDF defined in Section 3.6.1 of [SEC1]. #3 - We should amend the two sentences in 3.2.2 and 3.1.3 to say: The sending/receiving agent then performs the key deployment and key agreement operations of the Elliptic Curve DH/MQV Scheme specified in [SP800-56A], but uses the KDF defined in Section 3.6.1 of [SEC1]. #4 - We should add a new Section 7.1.6 titled Key Derivation Algorithm. The section will have one sentence: "The KDF used in this document is as specified in 3.6.1 of [SEC1]." spt From owner-ietf-smime@mail.imc.org Fri Nov 7 09:11: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 ACFEB28C106 for ; Fri, 7 Nov 2008 09:11:40 -0800 (PST) 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 d+VsTxjI0CFA for ; Fri, 7 Nov 2008 09:11:40 -0800 (PST) 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 69F1F28C0EB for ; Fri, 7 Nov 2008 09:11:39 -0800 (PST) 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 mA7GmgH2019673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Nov 2008 09:48: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 mA7GmgMr019671; Fri, 7 Nov 2008 09:48: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 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 mA7GmUus019649 for ; Fri, 7 Nov 2008 09:48:41 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 98346 invoked from network); 7 Nov 2008 16:48:30 -0000 Received: from unknown (HELO Wylie) (turners@96.241.99.222 with login) by smtp106.biz.mail.re2.yahoo.com with SMTP; 7 Nov 2008 16:48:29 -0000 X-YMail-OSG: 3L0jE6QVM1myMvb6lTgCaGQnGM_X_PQyXCbZtp6qpZ7xb730n4.53nzwP5Sf1qUUR.BhpGJP34HXhEnaTRor8MLPAl9bK3Ue_HRa6yJg2lDs.k75MNiEJ843wlcPOOtegURvkcQTMjRlzPTK61u8FQcZrrhLD7WIO5BcKDgCErx0jGTLsDF8vYpr6XmyvQ-- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: Subject: IPR Disclosure for RFC 2633, 3278, 3850, 3851, and IDs draft-ietf-smime-3851bis, draft-ietf-smime-multisig, draft-ietf-smime-sha2, draft-ietf-smime-3278bis Date: Fri, 7 Nov 2008 11:48:13 -0500 Organization: IECA, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AclA+J/qtASEvUxISiat67dsqXy+sA== Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Note that Certicom has submitted an IPR disclosure that addresses a number of RFCs and IDs in the S/MIME WG: https://datatracker.ietf.org/ipr/1004/ It updates IPR Disclosure #750. spt From danwen@arvig.net Sat Nov 8 00:37:08 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CB6E3A67FB for ; Sat, 8 Nov 2008 00:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.076 X-Spam-Level: X-Spam-Status: No, score=-99.076 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, UNPARSEABLE_RELAY=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 tHvPKnKnYw9f for ; Sat, 8 Nov 2008 00:37:08 -0800 (PST) Received: from arvig.net (smtp2-5.eot.com [209.81.96.182]) by core3.amsl.com (Postfix) with ESMTP id CB7C53A677C for ; Sat, 8 Nov 2008 00:37:07 -0800 (PST) Received: from arvig.net (unverified [127.0.0.1]) by arvig.net (SurgeMail 3.8k4) with ESMTP id 149576628-1752052 for multiple; Sat, 08 Nov 2008 02:35:15 -0600 To: (Recipient List Suppressed) Received: from 212.116.219.190 by HTTP Sender: danwen@arvig.net From: fedmortgage@live.com Reply-to: fedmortgage@live.com Subject: Bank Promo X-Mailer: Quality Web Email v3.1s X-Originating-IP: 212.116.219.190 Date: Sat, 08 Nov 2008 00:35:15 -0800 Priority: normal Message-id: <49154f43.1be.5d09.1929751551@arvig.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Authenticated-User: danwen@arvig.net X-Vpipe: restarted=25 started /var/surgemail/scavs.pl (/var/surgemail/scavs.pl) X-SpamDetect: : 0.639000 From3consonants=0.3, From: does not include a real name=0.3 X-IP-stats: Incoming Last 0, First 53, in=94, out=0, spam=0 ip=212.116.219.190 X-Originating-IP: 212.116.219.190 Να είναι νικήτρια των 85.000 δολαρίων και ένα δωρεάν ταξίδι στην Αμερική επιλέγοντας τον τυχερό αριθμό από το 1-500.Send τυχερός αριθμός που έχετε επιλέξει για στιγμιαίο λαχείο draw.This προώθηση είναι από ομοσπονδιακ ή τράπεζα υποθηκών. Να είναι νικήτρια των 85.000 δολαρίων και ένα δωρεάν ταξίδι στην Αμερική επιλέγοντας τον τυχερό αριθμό από το 1-500.Send τυχερός αριθμός που έχετε επιλέξει για στιγμιαίο λαχείο draw.This προώθηση είναι από ομοσπονδιακ ή τράπεζα υποθηκών. From Paxton-ajilekaj@0577.it Sat Nov 8 02:36: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 7A9D93A6910 for ; Sat, 8 Nov 2008 02:36:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[BAYES_80=2, 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_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, 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_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, 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 hPWbmUTwXTA9 for ; Sat, 8 Nov 2008 02:36:16 -0800 (PST) Received: from ppp-70-243-221-25.dsl.rcsntx.swbell.net (ppp-70-243-221-25.dsl.rcsntx.swbell.net [70.243.221.25]) by core3.amsl.com (Postfix) with ESMTP id B92513A6852 for ; Sat, 8 Nov 2008 02:36:16 -0800 (PST) To: Subject: invoice From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081108103616.B92513A6852@core3.amsl.com> Date: Sat, 8 Nov 2008 02:36:16 -0800 (PST)
Click Here!
From owner-ietf-smime@mail.imc.org Mon Nov 10 10:18: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 4D96328C11A for ; Mon, 10 Nov 2008 10:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcsvdFx6sshV for ; Mon, 10 Nov 2008 10:18:32 -0800 (PST) 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 B940C3A68BA for ; Mon, 10 Nov 2008 10:18:31 -0800 (PST) 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 mAAI26fY073604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Nov 2008 11:02:06 -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 mAAI26tk073603; Mon, 10 Nov 2008 11:02:06 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAAI250A073597 for ; Mon, 10 Nov 2008 11:02:05 -0700 (MST) (envelope-from wwwrun@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 30) id C55BC28C113; Mon, 10 Nov 2008 10:02:07 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , smime mailing list , smime chair Subject: Document Action: 'Identity-based Encryption Architecture and Supporting Data Structures' to Informational RFC Message-Id: <20081110180207.C55BC28C113@core3.amsl.com> Date: Mon, 10 Nov 2008 10:02:07 -0800 (PST) Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the following document: - 'Identity-based Encryption Architecture and Supporting Data Structures ' as an Informational RFC 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-ibearch-09.txt Technical Summary This document describes the security architecture required to implement identity-based encryption, a public-key encryption technology that uses a user's identity to generate their public key. Working Group Summary This document is a product of the S/MIME Working Group. There was very little public discussion about this draft. During WG last call comments were raised and addressed, and after last call some nits were addressed. Protocol Quality Tim Polk reviewed this document for the IESG. At least one implementation exists; no additional vendors have announced implementation plans. Note to RFC Editor (1) Please note that Intended Status should be Informational, not Standards Track. (The document header asserted Standards track.) (2) Please make the following substitution in section 8.2 OLD BEGIN algorithmOID ibeIdentityInfo ibeAuthData bodyTags END NEW Identity-based Encryption

Namespace for Identity-based Encryption

urn:ietf:params:xml:ns:ibe

RFCXXXX.

From owner-ietf-smime@mail.imc.org Mon Nov 10 10:20:53 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 887F628C146 for ; Mon, 10 Nov 2008 10:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53PTrb00nPrw for ; Mon, 10 Nov 2008 10:20:52 -0800 (PST) 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 2D6EE3A6A6C for ; Mon, 10 Nov 2008 10:20:51 -0800 (PST) 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 mAAI3Tfw073759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Nov 2008 11:03:29 -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 mAAI3TQr073758; Mon, 10 Nov 2008 11:03:29 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAAI3SCQ073751 for ; Mon, 10 Nov 2008 11:03:29 -0700 (MST) (envelope-from wwwrun@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 30) id 6512128C0F6; Mon, 10 Nov 2008 10:03:31 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , smime mailing list , smime chair Subject: Document Action: 'Using the Boneh-Franklin and Boneh-Boyen identity-based Encryption Algorithms with the Cryptographic Message Syntax (CMS)' to Informational RFC Message-Id: <20081110180331.6512128C0F6@core3.amsl.com> Date: Mon, 10 Nov 2008 10:03:31 -0800 (PST) Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the following document: - 'Using the Boneh-Franklin and Boneh-Boyen identity-based Encryption Algorithms with the Cryptographic Message Syntax (CMS) ' as an Informational RFC 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-bfibecms-10.txt Technical Summary This document describes the conventions for using the Boneh-Franklin (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in the Cryptographic Message Syntax (CMS) to encrypt content-encryption keys. Object identifiers and the convention for encoding a recipient's identity are also defined. Working Group Summary This document is a product of the S/MIME Working Group. There was very little public discussion about this draft. During WG last call comments were raised and addressed, and after last call some nits were addressed. Protocol Quality Tim Polk reviewed this document for the IESG. At least one implementation of this protocol exists; additional vendors have not expressed an intention to implement this protocol. Note to RFC Editor Please note that Intended Status should be Informational, not Standards Track. (The document header asserted Standards track.) From owner-ietf-smime@mail.imc.org Mon Nov 10 10:48: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 AD58128C18D for ; Mon, 10 Nov 2008 10:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.003 X-Spam-Level: X-Spam-Status: No, score=-104.003 tagged_above=-999 required=5 tests=[AWL=2.596, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngK4scuQWnOz for ; Mon, 10 Nov 2008 10:48:16 -0800 (PST) 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 BFB9528C15E for ; Mon, 10 Nov 2008 10:48:14 -0800 (PST) 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 mAAITw0L077518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Nov 2008 11:29: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 mAAITwkJ077517; Mon, 10 Nov 2008 11:29:58 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAAITwYM077510 for ; Mon, 10 Nov 2008 11:29:58 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 34F5928C137; Mon, 10 Nov 2008 10:30:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-smime@imc.org Subject: I-D ACTION:draft-ietf-smime-cms-rsa-kem-06.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081110183001.34F5928C137@core3.amsl.com> Date: Mon, 10 Nov 2008 10:30:01 -0800 (PST) Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Use of the RSA-KEM Key Transport Algorithm in CMS Author(s) : J. Randall, B. Kaliski Filename : draft-ietf-smime-cms-rsa-kem-06.txt Pages : 23 Date : 2008-11-10 The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) mechanism for transporting keying data to a recipient using the recipient's RSA public key. This document specifies the conventions for using the RSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax (CMS). The ASN.1 syntax is aligned with ANS X9.44 and ISO/IEC 18033-2. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-rsa-kem-06.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-cms-rsa-kem-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-10102636.I-D@ietf.org> --NextPart-- From aileendonovan@sympatico.ca Wed Nov 12 18:34: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 6963F3A682F for ; Wed, 12 Nov 2008 18:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.994 X-Spam-Level: X-Spam-Status: No, score=-1.994 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 0QfLlvF+uIHe for ; Wed, 12 Nov 2008 18:34:55 -0800 (PST) Received: from simmts8-srv.bellnexxia.net (simmts8-qfe0.srvr.bell.ca [206.47.199.166]) by core3.amsl.com (Postfix) with ESMTP id 4A8173A67FF for ; Wed, 12 Nov 2008 18:34:55 -0800 (PST) Received: from simip9-ac.srvr.bell.ca ([206.47.199.87]) by simmts8-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20081113023447.DQGJ22699.simmts8-srv.bellnexxia.net@simip9-ac.srvr.bell.ca> for ; Wed, 12 Nov 2008 21:34:47 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigvAKQdG0nOL8cR/2dsb2JhbACBdopDhhTBQQ Received: from simfep4.srvr.bell.ca (HELO smtpacout.sympatico.ca) ([206.47.199.17]) by simip9-ac.srvr.bell.ca with SMTP; 12 Nov 2008 21:38:34 -0500 X-Mailer: Openwave WebEngine, version 2.8.10 (webedge20-101-191-20030113) X-Originating-IP: [209.51.223.67] From: Reply-To: mredisonwalker104@btinternet.com To: Subject: You Have Won Date: Wed, 12 Nov 2008 21:34:47 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20081113023447.DQGJ22699.simmts8-srv.bellnexxia.net@simip9-ac.srvr.bell.ca> You have just been awarded of the sum of =A32,693,385GBP which was won b= y your E-MAIL Address in our UK Promo. Do get back to this office with yo= ur requirement such via (mredisonwalker104@btinternet.com) with your = Names :............... Address :................ Conntry :................ Phone No :.............. Occupation :.............. Age :................ Sex :................. Best Regard >From Mr.Edison Walker From owner-ietf-smime@mail.imc.org Thu Nov 13 10: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 199723A6966 for ; Thu, 13 Nov 2008 10:21:40 -0800 (PST) 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 VYGgd7ispD-Z for ; Thu, 13 Nov 2008 10:21:39 -0800 (PST) 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 B3F553A6949 for ; Thu, 13 Nov 2008 10:21:38 -0800 (PST) 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 mADI5S64023132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2008 11:05: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 mADI5S91023131; Thu, 13 Nov 2008 11:05: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 mADI5HHj023096 for ; Thu, 13 Nov 2008 11:05:27 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 76522 invoked from network); 13 Nov 2008 18:05:16 -0000 Received: from unknown (HELO Wylie) (turners@96.231.123.19 with login) by smtp109.biz.mail.re2.yahoo.com with SMTP; 13 Nov 2008 18:05:16 -0000 X-YMail-OSG: Ri.tU_gVM1m_idOWwjSdnYUy2kTDA3tdHEKziwqC7o5.8El79eiQasEt_7tHJ9H7AGpGPlGCCIfZuqlmwkVdTAkqs51YuwO.euS08PcIgI6RUnU126tvDKJO7slqEAKjKaD_ZkfSiDyRbtueS0ELKIKHJF8d8cZktQslvJgPMhiVobcHkDzvYRbzgwGW X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: , References: <20081030164211.D60EF3A684F@core3.amsl.com> Subject: RE: Last Call: draft-ietf-smime-3851bis (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification) to Proposed Standard Date: Thu, 13 Nov 2008 13:05:02 -0500 Organization: IECA, Inc. Message-ID: <6A85CB8D97994AB496262EFF38FD178B@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: Ack6rtPdEuque2DLR8yPNyX5TMydiwLCQuhA In-Reply-To: <20081030164211.D60EF3A684F@core3.amsl.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: One thing I noted is that to ensure interoperability of the SHOULD- for the DH ephemeral-static requirement we need to pick a MUST key wrap algorithm (note that E-S DH was a SHOULD in RFC 3851 but RFC 3851 did not include requirements for a key wrap algorithm). The text should not only indicate which key wrap algorithms to use but what kind of content encryption keys the algorithm is "good" for. I suggest adding the following text to Section 2.3 right after the bullets (all of the references were already normative references): When DH ephemeral-static is used, a key wrap algorithm is also specified in the KeyEncryptionAlgorithmIdentifier [CMS]. When DH ephemeral-static is used with an AES content encryption algorithm (see Section 2.7), the key wrap algorithm MUST be an AES key wrap algorithm from [CMSAES]. When DH ephemeral-static is used with the Triple DES content encryption algorithm (see Section 2.7), the key wrap algorithm MUST be either Triple DES key wrap from [CMSALG] or one of the AES key wraps from [CMSAES]. The strength of the key wrap algorithm MUST be as strong as the content encryption algorithm: - The Triple-DES key wrap algorithm can be used with the Triple-DES content encryption algorithm, - The AES 128 key wrap algorithm can be used with The Triple-DES and AES 128 content encryption algorithms, - The AES 192 key wrap algorithm can be used with The Triple-DES, AES 128, and AES 192 content encryption algorithms, - The AES 256 key wrap algorithm can be used with The Triple-DES, AES 128, AES 192, and AES 256 content encryption algorithms. spt >-----Original Message----- >From: ietf-announce-bounces@ietf.org >[mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG >Sent: Thursday, October 30, 2008 12:42 PM >To: IETF-Announce >Cc: ietf-smime@imc.org >Subject: Last Call: draft-ietf-smime-3851bis >(Secure/Multipurpose Internet Mail Extensions (S/MIME) Version >3.2 Message Specification) to Proposed Standard > >The IESG has received a request from the S/MIME Mail Security >WG (smime) to consider the following document: > >- 'Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 > Message Specification ' > as a Proposed Standard > >The IESG plans to make a decision in the next few weeks, and >solicits final comments on this action. > >In particular, the IESG solicits comments on the cryptographic >strength requirements specified in section 4.1 through 4.5, >and the following statement from Section 6, Security Considerations: > > "Today, 512-bit RSA, DSA and DH keys are considered by many experts > to be cryptographically insecure." > >These sections allow the continued use of RSA, DSA, and DH key >lengths between 512 and 1024 bits. Given that other >organizations are moving to a minimum key length of 2048 bits, >the IESG wishes to verify IETF consensus for the cryptographic >minimums in this document. > >Please send substantive comments to the >ietf@ietf.org mailing lists by 2008-11-13. Exceptionally, >comments may be sent to iesg@ietf.org instead. In either case, >please retain the beginning of the Subject line to allow >automated sorting. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-smime-3851bis-08.txt > > >IESG discussion can be tracked via >https://datatracker.ietf.org/public/pidtracker.cgi?command=view >_id&dTag=16577&rfc_flag=0 > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/ietf-announce From owner-ietf-smime@mail.imc.org Thu Nov 13 12:56: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 DC2473A68BA for ; Thu, 13 Nov 2008 12:56:45 -0800 (PST) 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 Nj9YuY3tMO8T for ; Thu, 13 Nov 2008 12:56:45 -0800 (PST) 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 D6FDC3A6807 for ; Thu, 13 Nov 2008 12:56:39 -0800 (PST) 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 mADKjuHa036988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2008 13:45: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 mADKju5Y036986; Thu, 13 Nov 2008 13:45: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 [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mADKjm4r036974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2008 13:45:49 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <6A85CB8D97994AB496262EFF38FD178B@Wylie> References: <20081030164211.D60EF3A684F@core3.amsl.com> <6A85CB8D97994AB496262EFF38FD178B@Wylie> Date: Thu, 13 Nov 2008 12:45:46 -0800 To: "Turner, Sean P." , , From: Paul Hoffman Subject: RE: Last Call: draft-ietf-smime-3851bis (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification) to Proposed Standard Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 1:05 PM -0500 11/13/08, Turner, Sean P. wrote: >One thing I noted is that to ensure interoperability of the SHOULD- for the >DH ephemeral-static requirement we need to pick a MUST key wrap algorithm >(note that E-S DH was a SHOULD in RFC 3851 but RFC 3851 did not include >requirements for a key wrap algorithm). The text should not only indicate >which key wrap algorithms to use but what kind of content encryption keys >the algorithm is "good" for. I suggest adding the following text to Section >2.3 right after the bullets (all of the references were already normative >references): > >When DH ephemeral-static is used, a key wrap algorithm is also specified in >the KeyEncryptionAlgorithmIdentifier [CMS]. When DH ephemeral-static is >used with an AES content encryption algorithm (see Section 2.7), the key >wrap algorithm MUST be an AES key wrap algorithm from [CMSAES]. When DH >ephemeral-static is used with the Triple DES content encryption algorithm >(see Section 2.7), the key wrap algorithm MUST be either Triple DES key wrap >from [CMSALG] or one of the AES key wraps from [CMSAES]. The strength of >the key wrap algorithm MUST be as strong as the content encryption >algorithm: > >- The Triple-DES key wrap algorithm can be used with the Triple-DES content > encryption algorithm, >- The AES 128 key wrap algorithm can be used with The Triple-DES and AES 128 > content encryption algorithms, >- The AES 192 key wrap algorithm can be used with The Triple-DES, AES 128, > and AES 192 content encryption algorithms, >- The AES 256 key wrap algorithm can be used with The Triple-DES, AES 128, > AES 192, and AES 256 content encryption algorithms. Wouldn't it be much simpler to say that the key wrap algorithm must be the same as the content encryption algorithm? Yes, one *might* want a keywrap of greater strength as you have above, but that forces implementations to have tables of what "greater" means. Saying they need to be the same is much more straight forward. From owner-ietf-smime@mail.imc.org Thu Nov 13 13:10: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 62ABD3A692E for ; Thu, 13 Nov 2008 13:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.843 X-Spam-Level: X-Spam-Status: No, score=-101.843 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, 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 NyIvOqRWexno for ; Thu, 13 Nov 2008 13:10:20 -0800 (PST) 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 40DDF3A6807 for ; Thu, 13 Nov 2008 13:10:20 -0800 (PST) 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 mADL0qfo037612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2008 14:00:52 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mADL0qPO037611; Thu, 13 Nov 2008 14:00:52 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mADL0fNw037593 for ; Thu, 13 Nov 2008 14:00:51 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200811132100.mADL0fNw037593@balder-227.proper.com> Received: (qmail 20543 invoked by uid 0); 13 Nov 2008 21:00:34 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 13 Nov 2008 21:00:34 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 13 Nov 2008 16:00:37 -0500 To: Paul Hoffman , "Turner, Sean P." , , From: Russ Housley Subject: RE: Last Call: draft-ietf-smime-3851bis (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification) to Proposed Standard In-Reply-To: References: <20081030164211.D60EF3A684F@core3.amsl.com> <6A85CB8D97994AB496262EFF38FD178B@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: > >One thing I noted is that to ensure interoperability of the SHOULD- for the > >DH ephemeral-static requirement we need to pick a MUST key wrap algorithm > >(note that E-S DH was a SHOULD in RFC 3851 but RFC 3851 did not include > >requirements for a key wrap algorithm). The text should not only indicate > >which key wrap algorithms to use but what kind of content encryption keys > >the algorithm is "good" for. I suggest adding the following text to Section > >2.3 right after the bullets (all of the references were already normative > >references): > > > >When DH ephemeral-static is used, a key wrap algorithm is also specified in > >the KeyEncryptionAlgorithmIdentifier [CMS]. When DH ephemeral-static is > >used with an AES content encryption algorithm (see Section 2.7), the key > >wrap algorithm MUST be an AES key wrap algorithm from [CMSAES]. When DH > >ephemeral-static is used with the Triple DES content encryption algorithm > >(see Section 2.7), the key wrap algorithm MUST be either Triple DES key wrap > >from [CMSALG] or one of the AES key wraps from [CMSAES]. The strength of > >the key wrap algorithm MUST be as strong as the content encryption > >algorithm: > > > >- The Triple-DES key wrap algorithm can be used with the Triple-DES content > > encryption algorithm, > >- The AES 128 key wrap algorithm can be used with The Triple-DES and AES 128 > > content encryption algorithms, > >- The AES 192 key wrap algorithm can be used with The Triple-DES, AES 128, > > and AES 192 content encryption algorithms, > >- The AES 256 key wrap algorithm can be used with The Triple-DES, AES 128, > > AES 192, and AES 256 content encryption algorithms. > >Wouldn't it be much simpler to say that the key wrap algorithm must >be the same as the content encryption algorithm? Yes, one *might* >want a keywrap of greater strength as you have above, but that >forces implementations to have tables of what "greater" means. >Saying they need to be the same is much more straight forward. The keysize could be the same, but the mode will probably be different. One would not want to use AES Key Wrap for the content. Russ From owner-ietf-smime@mail.imc.org Thu Nov 13 13:21: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 7E8A53A698B for ; Thu, 13 Nov 2008 13:21:21 -0800 (PST) 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 kNA0cXA8jLmh for ; Thu, 13 Nov 2008 13:21:20 -0800 (PST) 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 5F19F3A685C for ; Thu, 13 Nov 2008 13:21:20 -0800 (PST) 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 mADLBjZB038133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2008 14:11: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 mADLBi2P038132; Thu, 13 Nov 2008 14:11:44 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mADLBa2o038112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2008 14:11:37 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200811132100.mADL0f60037594@balder-227.proper.com> References: <20081030164211.D60EF3A684F@core3.amsl.com> <6A85CB8D97994AB496262EFF38FD178B@Wylie> <200811132100.mADL0f60037594@balder-227.proper.com> Date: Thu, 13 Nov 2008 13:11:34 -0800 To: Russ Housley , "Turner, Sean P." , , From: Paul Hoffman Subject: RE: Last Call: draft-ietf-smime-3851bis (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification) to Proposed Standard Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 4:00 PM -0500 11/13/08, Russ Housley wrote: >>Wouldn't it be much simpler to say that the key wrap algorithm must be the same as the content encryption algorithm? Yes, one *might* want a keywrap of greater strength as you have above, but that forces implementations to have tables of what "greater" means. Saying they need to be the same is much more straight forward. > >The keysize could be the same, but the mode will probably be different. One would not want to use AES Key Wrap for the content. Sorry, of course. I meant "same underlying encryption function", not "same algorithm". From owner-ietf-smime@mail.imc.org Thu Nov 13 14:04: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 7CECC3A69CF for ; Thu, 13 Nov 2008 14:04:38 -0800 (PST) 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 5aK8BIT6VGPy for ; Thu, 13 Nov 2008 14:04:37 -0800 (PST) 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 571C23A68AB for ; Thu, 13 Nov 2008 14:04:37 -0800 (PST) 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 mADLrAe7039892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2008 14:53: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 mADLrABV039891; Thu, 13 Nov 2008 14:53: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 smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mADLqwCZ039869 for ; Thu, 13 Nov 2008 14:53:09 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 90791 invoked from network); 13 Nov 2008 21:52:53 -0000 Received: from unknown (HELO Wylie) (turners@96.231.123.19 with login) by smtp107.biz.mail.re2.yahoo.com with SMTP; 13 Nov 2008 21:52:53 -0000 X-YMail-OSG: 1H.4_.UVM1nQ3PUr2KitvORwKCU6AE2dZktgawIDRgkDagAzErh9YGDgySBKzhKiaFYutlPHT2TtDg.b4VsbsAB0GilRY6W8ks08_5yuwZ2pSj1BWEF_xKh7ABLwLLLB0oajMiXPwp3Wf9BkwTmXgFOfMfX5r45YvMcMeLLvjDFB7ve3.I_u3r_r0PML X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "'Paul Hoffman'" , "'Russ Housley'" , , References: <20081030164211.D60EF3A684F@core3.amsl.com> <6A85CB8D97994AB496262EFF38FD178B@Wylie> <200811132100.mADL0f60037594@balder-227.proper.com> Subject: RE: Last Call: draft-ietf-smime-3851bis (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification) to Proposed Standard Date: Thu, 13 Nov 2008 16:52:39 -0500 Organization: IECA, Inc. Message-ID: <6DE25C581C4E42ED81E5E96388C19658@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AclF1GqQbAiaJSExT/+8S8a/2jE3qAAAdI+Q In-Reply-To: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >-----Original Message----- >From: Paul Hoffman [mailto:phoffman@imc.org] >Sent: Thursday, November 13, 2008 4:12 PM >To: Russ Housley; Turner, Sean P.; iesg@ietf.org; ietf-smime@imc.org >Subject: RE: Last Call: draft-ietf-smime-3851bis >(Secure/Multipurpose Internet Mail Extensions (S/MIME) Version >3.2 Message Specification) to Proposed Standard > >At 4:00 PM -0500 11/13/08, Russ Housley wrote: >>>Wouldn't it be much simpler to say that the key wrap >algorithm must be the same as the content encryption >algorithm? Yes, one *might* want a keywrap of greater strength >as you have above, but that forces implementations to have >tables of what "greater" means. Saying they need to be the >same is much more straight forward. >> >>The keysize could be the same, but the mode will probably be >different. One would not want to use AES Key Wrap for the content. > >Sorry, of course. I meant "same underlying encryption >function", not "same algorithm". Paul, Yes, it would be simpler. When DH ephemeral-static is used, a key wrap algorithm is also specified in the KeyEncryptionAlgorithmIdentifier [CMS]. The underlying encryption functions for the key wrap and content encryption algorithms ([CMSALG] and [CMSAES]) and the key sizes for the two algorithms MUST be the same (e.g., AES 128 key wrap algorithm with AES 128 content encryption algorithm). As AES 128 CBC is the mandatory to implement content encryption algorithm thus, when DH ephemeral-static is supported, AES-128 key wrap algorithm MUST also be supported. spt From owner-ietf-smime@mail.imc.org Thu Nov 13 17:15: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 3215E3A6A2E for ; Thu, 13 Nov 2008 17:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.437 X-Spam-Level: * X-Spam-Status: No, score=1.437 tagged_above=-999 required=5 tests=[AWL=0.186, 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 G5zN3T7t+x0n for ; Thu, 13 Nov 2008 17:15:17 -0800 (PST) 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 0E8643A6A24 for ; Thu, 13 Nov 2008 17:15:16 -0800 (PST) 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 mAE0qGZd047388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2008 17:52: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 mAE0qGY0047387; Thu, 13 Nov 2008 17:52: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 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 mAE0q3ZT047378 for ; Thu, 13 Nov 2008 17:52:15 -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 AA152433837; Fri, 14 Nov 2008 01:50:37 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id BAA19456; Fri, 14 Nov 2008 01:50:36 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200811140050.BAA19456@TR-Sys.de> Subject: draft-ietf-smime-3278bis-03 incremental review To: ietf-smime@imc.org Date: Fri, 14 Nov 2008 01:50:36 +0100 (MEZ) 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: Folks, I have performed another (incremental) review of draft-ietf-smime-3278bis-03 and I apologize that it could not be completed in time. Nevertheless, I hope it will still be useful. The only significant proposal I have is based on the observation that the change information vs. RFC 3278 has grown to an extent that it better should be moved to the end of the document (new Appendix B ?). The carefully collected information there should be kept in this detail for historical record, and to educate implementors tackling software updates, but it now seems to over-stress the basic character of an Introduction. Beyond that, I found a bunch of editorials that will be sent off-list (ASAP, I hope tomorrow), after a final cross-checking with Sean's summary posted on 6 Nov 2008 (to remove potential redundancy). My primary conclusion is that the draft should go ahead after the next minor polishing update to address the comments. Sean and Dan: please still be patient for the details to come. 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 | +------------------------+--------------------------------------------+ From owner-ietf-smime@mail.imc.org Fri Nov 14 03:51: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 351D23A6A6B for ; Fri, 14 Nov 2008 03:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.53 X-Spam-Level: * X-Spam-Status: No, score=1.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 bVpOCme8YCv8 for ; Fri, 14 Nov 2008 03:51:42 -0800 (PST) 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 E7B683A6A69 for ; Fri, 14 Nov 2008 03:51:41 -0800 (PST) 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 mAEBdYQp078472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Nov 2008 04:39: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 mAEBdYoR078471; Fri, 14 Nov 2008 04:39: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 ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAEBdLjJ078430 for ; Fri, 14 Nov 2008 04:39:32 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 009DF2E; Fri, 14 Nov 2008 12:39:17 +0100 (CET) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2008111412391565:218695 ; Fri, 14 Nov 2008 12:39:15 +0100 Message-ID: <491D62A7.8090809@edelweb.fr> Date: Fri, 14 Nov 2008 12:36:07 +0100 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 Cc: iesg@ietf.org, ietf-smime@imc.org, turners@ieca.com Subject: Last Call: draft-ietf-smime-3851bis (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification) to Proposed Standard References: <20081030164211.D60EF3A684F@core3.amsl.com> <6A85CB8D97994AB496262EFF38FD178B@Wylie> <200811132100.mADL0f60037594@balder-227.proper.com> In-Reply-To: X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 11/14/2008 12:39:15 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 11/14/2008 12:39:16 PM, Serialize complete at 11/14/2008 12:39:16 PM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000108070309040400080706" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000108070309040400080706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Would it be possible to add a comment concerning the multipart/signed creation or better some section mulipart/signed parsing that a system should nicely treat a multipart/signed message that has more than two parts. It may be not the right doc, probably better in CMS. it happens that some firewalls add "disclaimers" as an additional body-part as soon as they see that the top level mime is multipart/* At least one well known user agent refuses to show such messages. TIA for consideration. Peter Sylvester --------------ms000108070309040400080706 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOhTCC BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggWVMIIDMKADAgECAgYKwoI0lJgwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDcwNjI4MTc0MDU0WhcNMTQwNTAyMTc0 MDU0WjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4GgMIGdMDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAfBgNV HSMEGDAWgBSo2SuP1LBnur1JXLwz/HdSEblnnTANBgkqhkiG9w0BAQUFAAOCAk4AUgtIR4Jh Ynyk939SM6X4YZPNYIgDio8Gp064P1MBILDgI/hzSwyxT5bb1qUQub+icXO9/5ufsDufr/ff 2gCzKMuo3hC26iey630PzHTvJgrTcEp9c92IZPt3UKeouqy+95Lz2r58dbfouKLZVwiKQ0jP 2c2U5tPWmzW4CAjFWUKRYlrhbt+tjzW8CAA0DHO1xrrzAuTyuGNKcH4LlLuVo7MbDPn/uLma 1fAVYvH2c6OTwGHJyKTQVveYw4UqgAhErJMFWJDKm+Q9h91mCzkjrA1Eu0nVDUTV1+dW6mNT DPLIq0qSdqP7iT2WcNzQVy/0PiXT2aaEH9lE2W1SSD6PnT8y+aqJTGjRMK1cl7VSJHxbq8U9 lIS+6eiV5VrogAa8X52pKF0u91i+/CBZ3e5Mi2/BwMrMN/mXA/ZwL3p+jZpnijpqnqdz8iCn qR9ExhR+BpN/b56RqEu7llLrcwOS44kjbubALjxe0+XutidWjt/6/tLYuM7rJ6Hk1EweFGVd kRejKogD3GzZ3gOAIF/D28VBJcTRcyF7OI/k/3jPD0gHUGN1uxk2Krz8SE9GEPvP/JehCBl/ FrQOCsEUmszi7Se0Vxr2k1P7icxT7L/AcWt/djIgp/vsQNurbi0+5+q7YS2b2bc1HchjsmaI cXy8ha5IGk4+F1qrHZsGqTm5M7TzZN6k0X2llMaozrtPzxNMC6uvf1uRvHYHf1x0Q0pdxTzZ PuuFw1PUlu6o5xPHbf3ZgC7ZNSDry13ZEXmlG2Re0u9WwEJJ1nYqlcDvNzGCAq4wggKqAgEB MGUwWzELMAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2Ug RWRlbFBLSTEgMB4GA1UEAxMXRWRlbFBLSSBFZGVsV2ViIFBlcnNHRU4CBgqvijKA3jAJBgUr DgMCGgUAoIIBnzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w ODExMTQxMTM2MDdaMCMGCSqGSIb3DQEJBDEWBBTTSDhAyDd5gascjzefTGI/bcIrMDBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB0BgkrBgEEAYI3EAQxZzBlMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wdgYLKoZIhvcNAQkQAgsxZ6Bl MFsxCzAJBgNVBAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVk ZWxQS0kxIDAeBgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wDQYJKoZI hvcNAQEBBQAEgYBSJC3iw+YmQwBLHKJNk9mJzSsIeG7I08+EiBmKaw8fdkZ7uU/Jg++TIJTN 0H2e6lTxAl8dZqh5DuqQmOwV/LQwnv1V4EPmcp2KbVEmbkrKFtDc/W4ufzmgXvo65sbUeBn7 AtMyl9RF4M3LoWuW6IMsufBd8qdMcqNcG+9AbyZSDQAAAAAAAA== --------------ms000108070309040400080706-- From owner-ietf-smime@mail.imc.org Fri Nov 14 10:45: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 966AC3A68A2 for ; Fri, 14 Nov 2008 10:45:05 -0800 (PST) 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=[BAYES_00=-2.599, 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 d3D95SaB+5YX for ; Fri, 14 Nov 2008 10:45:04 -0800 (PST) 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 6C1C33A67D8 for ; Fri, 14 Nov 2008 10:45:04 -0800 (PST) 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 mAEIXMth002666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Nov 2008 11:33: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 mAEIXMP6002665; Fri, 14 Nov 2008 11:33: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 smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mAEIXAXQ002650 for ; Fri, 14 Nov 2008 11:33:21 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 19528 invoked from network); 14 Nov 2008 18:33:10 -0000 Received: from unknown (HELO Wylie) (turners@96.241.7.41 with login) by smtp104.biz.mail.re2.yahoo.com with SMTP; 14 Nov 2008 18:33:10 -0000 X-YMail-OSG: nXSJSEsVM1mCmHfjO7KfIONDbCSHd4u0jqy729vcHQ4e6lbB0gW08SaRyMgU1wjsdey9xdrtYdUWARbe77a8eD5miX5gDxzJEL_BIl7xaX1MmbPDPYtdihPDYBo8.yPSzJHwuwWWUhF3O4EMvMWWvLi3B5yC0s1cwkZ9l4s_JlRKpXacAeI4NlwNa9IQ X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "=?iso-8859-1?Q?'Alfred_H=CEnes'?=" , References: <200811140050.BAA19456@TR-Sys.de> Subject: RE: draft-ietf-smime-3278bis-03 incremental review Date: Fri, 14 Nov 2008 13:32:53 -0500 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AclF9nJgcRuG/gDXSjGaTLFVj4BDLAAkNUyg In-Reply-To: <200811140050.BAA19456@TR-Sys.de> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alfred, I should have a version that incorporates all of you changes by the end = of next week. spt=20 >-----Original Message----- >From: owner-ietf-smime@mail.imc.org=20 >[mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Alfred H=CEnes >Sent: Thursday, November 13, 2008 7:51 PM >To: ietf-smime@imc.org >Subject: draft-ietf-smime-3278bis-03 incremental review > > >Folks, >I have performed another (incremental) review of > draft-ietf-smime-3278bis-03 >and I apologize that it could not be completed in time. >Nevertheless, I hope it will still be useful. > >The only significant proposal I have is based on the=20 >observation that the change information vs. RFC 3278 has grown=20 >to an extent that it better should be moved to the end of the=20 >document (new Appendix B ?). >The carefully collected information there should be kept in=20 >this detail for historical record, and to educate implementors=20 >tackling software updates, but it now seems to over-stress the=20 >basic character of an Introduction. > >Beyond that, I found a bunch of editorials that will be sent=20 >off-list (ASAP, I hope tomorrow), after a final cross-checking=20 >with Sean's summary posted on 6 Nov 2008 (to remove potential=20 >redundancy). > >My primary conclusion is that the draft should go ahead after=20 >the next minor polishing update to address the comments. > > >Sean and Dan: please still be patient for the details to come. > > >Kind regards, > Alfred H=CEnes. > >--=20 > >+------------------------+--------------------------------------------+ >| 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 | >+------------------------+--------------------------------------------+ > From 3dkollg@ka-muenchen.de Mon Nov 17 11:09:17 2008 Return-Path: <3dkollg@ka-muenchen.de> 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 ABB7A3A68A2 for ; Mon, 17 Nov 2008 11:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.171 X-Spam-Level: X-Spam-Status: No, score=-22.171 tagged_above=-999 required=5 tests=[BAYES_80=2, HELO_DYNAMIC_HCC=4.295, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, 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, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, SUBJ_ALL_CAPS=2.077, 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 F+vZqWApqfre for ; Mon, 17 Nov 2008 11:09:17 -0800 (PST) Received: from cpc2-stre1-0-0-cust439.bagu.cable.ntl.com (cpc2-stre1-0-0-cust439.bagu.cable.ntl.com [86.15.105.184]) by core3.amsl.com (Postfix) with SMTP id 8CBD13A689E for ; Mon, 17 Nov 2008 11:09:15 -0800 (PST) Message-Id: <20081117070906.4277.qmail@cpc2-stre1-0-0-cust439.bagu.cable.ntl.com> To: Subject: RE: SALE 89% OFF From: VIAGRA INC MIME-Version: 1.0 Content-Type: text/html Date: Mon, 17 Nov 2008 11:09:15 -0800 (PST)
From owner-ietf-smime@mail.imc.org Thu Nov 20 13:05: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 EFDFE3A6AF5 for ; Thu, 20 Nov 2008 13:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 IZBoZhL5AEja for ; Thu, 20 Nov 2008 13:05:57 -0800 (PST) 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 39C653A677D for ; Thu, 20 Nov 2008 13:05:56 -0800 (PST) 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 mAKJjOoY029097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2008 12:45: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 mAKJjOiG029096; Thu, 20 Nov 2008 12:45:24 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp101.biz.mail.mud.yahoo.com (smtp101.biz.mail.mud.yahoo.com [68.142.200.236]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mAKJjDIT029068 for ; Thu, 20 Nov 2008 12:45:23 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 45920 invoked from network); 20 Nov 2008 19:45:12 -0000 Received: from unknown (HELO Wylie) (turners@130.129.29.26 with login) by smtp101.biz.mail.mud.yahoo.com with SMTP; 20 Nov 2008 19:45:12 -0000 X-YMail-OSG: W4GEGooVM1lL2xKV2viPjF4bS.LhPbhHdlMV0z9FbGlDZcNa1_sRpJtqvewpgzglalzrqwKaZ4ZT6fS7hzzWbj7zO09ZNgTeLxIDHbvFfD.9ReGIBr7IewaLxrM5VYOJgzB_8P8DmAqTW_eXSfc1nnrNwIezFQCvMzbmt55J X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "secdir" Cc: Subject: SMIME WG summary Date: Thu, 20 Nov 2008 13:44:47 -0600 Organization: IECA, Inc. Message-ID: <6C0AE36C1E164AA5AF1A6EAAA3A08991@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AclLSHHdw4pey/R4Q1SH0WsjF38iLA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The SMIME WG did not meeting at IETF 73. The SMIME WG has 9 IDs. Here is the status of those IDs: In RFC Editors Queue: - draft-ietf-smime-multisig: Pinned on draft-ietf-smime-3850bis & draft-ietf-smime-3850bis IDs. - draft-ietf-smime-ibearch: In EDIT state. - draft-ietf-smime-bfibecms: In EDIT state. With AD (status: Passed IETF LC) - draft-ietf-smime-3850bis: Awaiting GEN-ART comments - draft-ietf-smime-3851bis: Addressed IETF LC comments. Will publish when GEN-ART comments on draft-ietf-smime-3850bis are addressed. With AD (status: In 2nd IETF LC): - draft-ietf-smime-sha2: No comments so far. With AD (status: Awaiting new ID from authors): - draft-ietf-smime-rfc3278-update: Addressing WG LC comments. New version published shortly after meeting. Expected to go to WG LC. - draft-ietf-smime-cms-rsa-kem: A new version was posted, but another is needed to address Steve Kent's SECDIR comments. With WG - draft-ietf-smime-new-asn1: This ID updates many/most of the ASN.1 modules in the S/MIME WG to the '02 ASN.1. The authors want reviewers. It is expected that the ID will be ready for WG LC in December '08. spt From owner-ietf-smime@mail.imc.org Sat Nov 22 00: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 B2C333A692B for ; Sat, 22 Nov 2008 00:55:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] 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 NovKBoSCr8fa for ; Sat, 22 Nov 2008 00:55:35 -0800 (PST) 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 4B7283A684F for ; Sat, 22 Nov 2008 00:55:34 -0800 (PST) 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 mAM8b1XX008465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Nov 2008 01:37: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 mAM8b1ZF008464; Sat, 22 Nov 2008 01:37: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 pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAM8aoak008445 for ; Sat, 22 Nov 2008 01:37:01 -0700 (MST) (envelope-from anders.rundgren@telia.com) Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn2.hy.skanova.net (7.3.129) id 48A144C501AE708E for ietf-smime@imc.org; Sat, 22 Nov 2008 09:36:50 +0100 Message-ID: From: "Anders Rundgren" To: Subject: Slamming S/MIME. Re: How-to guide for email encryption Date: Sat, 22 Nov 2008 09:36:52 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006D_01C94C85.D9E3DC00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.20661 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_006D_01C94C85.D9E3DC00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >From a recent Mozilla discussion... Services like Skype already provide end-to-end encryption to hundreds of = millions of users without any need for a guide or so. S/MIME encryption OTOH is a dated off-line scheme requiring message = encryption and decryption, while still not addressing core issues such = as who is talking to who, although that becomes fairly irrelevant since = there are no users worth mentioning. It is in this context worth mentioning that governments in the EU are = creating WS*-based messaging frameworks that (within their own community = at least) offer transparent encryption and signatures. Due to the fact = that governments should not indulge in secret actions (excluding CIA = here), encryption at the service level is exactly what they want; i.e. = you should be able to see what has been exchanged based on logging. How can you trust a service? I don't have a conclusive answer to that = except that this is a fact, otherwise Microsoft Live, Google mail, and = hundreds of thousands of other "cloud computing" services wouldn't = exist. Another related issue is secure citizen-to-government communication. In = the EU, practically all states work with centralized mail-boxes on the = web to which you authenticate to. My own work FWIW, is very much = focused on these developments because they have proved to scale and are = in fact just government versions of Microsoft's and Google's stuff. Please go ahead with S/MIME but be aware that the odds that you succeed = are extremely low. If I had an interest in scalable secure end-to-end = messaging, I would start with a blank piece of paper and see what the = options are. In case you do, please send me the draft because I'm still = a little bit curious at least :-) Sincerely Anders Rundgren ------=_NextPart_000_006D_01C94C85.D9E3DC00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
From a recent Mozilla = discussion...
 
Services like Skype already provide = end-to-end=20 encryption to hundreds of millions of users without any need for a guide = or=20 so.
 
S/MIME encryption OTOH is a dated = off-line scheme=20 requiring message encryption and decryption, while still not addressing = core=20 issues such as who is talking to who, although that becomes fairly = irrelevant=20 since there are no users worth mentioning.
 
It is in this context worth mentioning = that=20 governments in the EU are creating WS*-based messaging frameworks that = (within=20 their own community at least) offer transparent encryption and=20 signatures.   Due to the fact that governments should not = indulge in=20 secret actions (excluding CIA here), encryption at the service level is = exactly=20 what they want; i.e. you should be able to see what has been exchanged = based on=20 logging.
 
How can you trust a service?  I = don't have a=20 conclusive answer to that except that this is a fact, otherwise = Microsoft=20 Live, Google mail, and hundreds of thousands of other "cloud = computing"=20 services wouldn't exist.
 
Another related issue is secure=20 citizen-to-government communication.  In the EU, practically all = states=20 work with centralized mail-boxes on the web to which you authenticate = to. =20 My own work FWIW, is very much focused on these developments because = they have=20 proved to scale and are in fact just government versions of Microsoft's = and=20 Google's stuff.
 
Please go ahead with S/MIME but be = aware that the=20 odds that you succeed are extremely low.   If I had an = interest in=20 scalable secure end-to-end messaging, I would start with a blank = piece of=20 paper and see what the options are.  In case you do, please send=20 me the draft because I'm still a little bit curious at least=20 :-)
 
Sincerely
Anders = Rundgren
------=_NextPart_000_006D_01C94C85.D9E3DC00-- From minor@air-worldwide.com Mon Nov 24 20:43: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 670E73A6BD8 for ; Mon, 24 Nov 2008 20:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -35.697 X-Spam-Level: X-Spam-Status: No, score=-35.697 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, 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, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_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 NcV-XVAPEqqA for ; Mon, 24 Nov 2008 20:43:28 -0800 (PST) Received: from agri-fab.com (unknown [122.161.16.253]) by core3.amsl.com (Postfix) with SMTP id 73B653A691A for ; Mon, 24 Nov 2008 20:43:26 -0800 (PST) To: Subject: Neverending party From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081125044327.73B653A691A@core3.amsl.com> Date: Mon, 24 Nov 2008 20:43:26 -0800 (PST)
From mercerme@jmu.edu Tue Nov 25 14:25: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 BF94028C1CF; Tue, 25 Nov 2008 14:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.616 X-Spam-Level: ** X-Spam-Status: No, score=2.616 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_93=0.6, LOTTERY_PH_004470=2.015] 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 FMUBxKSIifHN; Tue, 25 Nov 2008 14:25:54 -0800 (PST) Received: from mpdir6.jmu.edu (mpdir6.jmu.edu [134.126.12.45]) by core3.amsl.com (Postfix) with ESMTP id BC26628C1C3; Tue, 25 Nov 2008 14:25:53 -0800 (PST) Received: from mpmail1.jmu.edu (mpmail1.jmu.edu [134.126.13.21]) by mpdir6.jmu.edu (MOS 3.8.7a) with ESMTP id HAL55318; Tue, 25 Nov 2008 17:19:46 -0500 (EST) Received: (from mpmail1.jmu.edu [134.126.12.43]) by mpmail1.jmu.edu (MOS 3.8.7a) with HTTPS/1.1 id BTQ49006 (AUTH mercerme@jmu.edu); Tue, 25 Nov 2008 17:24:10 -0500 (EST) From: Uk National Lottery Subject: Your Email Emerge Winner Reply-To: contact.jakesanthony02@gmail.com X-Mailer: Mirapoint Webmail Direct 3.8.7a MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20081125172410.BTQ49006@mpmail1.jmu.edu> Date: Tue, 25 Nov 2008 17:24:10 -0500 (EST) X-Junkmail-Whitelist: YES (by domain whitelist at mpdir6.jmu.edu) To: undisclosed-recipients:; You won the sum of =A31,500,000 GBP from our monthly UK NATIONAL LOTTE= RYONLINE PROMOTION,you are there by adviced to get back to us, to claim = your prize. Contact:Mr.Jakes Anthony Tel: +44 702 401 4820 Email: con= tact.jakesanthony02@gmail.com Claims Requirements: 1.full name: 2.Hom= e Address: Regards, Mrs. Amanda Collins (Online Coordinator) From nkn2-ya3dd@air.nittsu.co.jp Wed Nov 26 04:46:08 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05F883A69B4 for ; Wed, 26 Nov 2008 04:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.196 X-Spam-Level: X-Spam-Status: No, score=-13.196 tagged_above=-999 required=5 tests=[BAYES_99=3.5, 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=3.493, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IP_ADDR=1.119, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_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 K0NaCljYuj6q for ; Wed, 26 Nov 2008 04:46:07 -0800 (PST) Received: from 91.18.220.87.dynamic.jazztel.es (91.18.220.87.dynamic.jazztel.es [87.220.18.91]) by core3.amsl.com (Postfix) with SMTP id 3CE0728C170 for ; Wed, 26 Nov 2008 04:46:04 -0800 (PST) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081126124606.3CE0728C170@core3.amsl.com> Date: Wed, 26 Nov 2008 04:46:04 -0800 (PST)
Click here to view as a webpage From nn@3abn.org Thu Nov 27 02:07: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 DB1D43A67D8 for ; Thu, 27 Nov 2008 02:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.962 X-Spam-Level: X-Spam-Status: No, score=-9.962 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, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, SARE_RECV_SPAM_DOMN02=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_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 h2YEyQyUuKT1 for ; Thu, 27 Nov 2008 02:07:06 -0800 (PST) Received: from 200-161-72-80.dsl.telesp.net.br (200-161-72-80.dsl.telesp.net.br [200.161.72.80]) by core3.amsl.com (Postfix) with SMTP id 1F9593A67E5 for ; Thu, 27 Nov 2008 02:07:03 -0800 (PST) To: Subject: Your order From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081127100704.1F9593A67E5@core3.amsl.com> Date: Thu, 27 Nov 2008 02:07:03 -0800 (PST) Click here to view as a webpage From liea@americanstoploss.com Sat Nov 29 03:59: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 EDA1028C11F for ; Sat, 29 Nov 2008 03:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.675 X-Spam-Level: X-Spam-Status: No, score=-22.675 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, 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_XBL=3.033, SARE_HTML_A_BODY=0.742, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, 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 rycyvBmraqqM for ; Sat, 29 Nov 2008 03:59:58 -0800 (PST) Received: from host-738.ibselektronics.pl (host-738.ibselektronics.pl [81.15.142.226]) by core3.amsl.com (Postfix) with SMTP id 0AC9828C115 for ; Sat, 29 Nov 2008 03:59:56 -0800 (PST) To: Subject: RE: Message 75517 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081129115957.0AC9828C115@core3.amsl.com> Date: Sat, 29 Nov 2008 03:59:56 -0800 (PST) Click here to view as a webpage.


Windows Live Customer Support | Hotmail Support FAQs | Newsletter feedback

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052 As a Windows Live member you have received this e-mail to inform you of updates, changes to the service, or special news and information vital to the service. Our policy is to send e-mail messages only to announce such information, and we'll continue to honor this policy. These communications are required as a part of this service. If you do not wish to receive these letters you may discontinue your participation in the service and close your account.

Microsoft respects your privacy. To learn more, please read our online Privacy Statement

Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
From obutt@aftrahr.com Sun Nov 30 17:26: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 EA5B83A6A99 for ; Sun, 30 Nov 2008 17:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -49.632 X-Spam-Level: X-Spam-Status: No, score=-49.632 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DE=0.35, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_JP_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 tVVlLmpcWxhD for ; Sun, 30 Nov 2008 17:26:51 -0800 (PST) Received: from f054053097.adsl.alicedsl.de (f054053097.adsl.alicedsl.de [78.54.53.97]) by core3.amsl.com (Postfix) with SMTP id 411C63A6A7D for ; Sun, 30 Nov 2008 17:26:49 -0800 (PST) To: Subject: Re: Order status From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081201012650.411C63A6A7D@core3.amsl.com> Date: Sun, 30 Nov 2008 17:26:49 -0800 (PST) Click here to view as a webpage. 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 mAM8b1XX008465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Nov 2008 01:37: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 mAM8b1ZF008464; Sat, 22 Nov 2008 01:37: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 pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAM8aoak008445 for ; Sat, 22 Nov 2008 01:37:01 -0700 (MST) (envelope-from anders.rundgren@telia.com) Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn2.hy.skanova.net (7.3.129) id 48A144C501AE708E for ietf-smime@imc.org; Sat, 22 Nov 2008 09:36:50 +0100 Message-ID: From: "Anders Rundgren" To: Subject: Slamming S/MIME. Re: How-to guide for email encryption Date: Sat, 22 Nov 2008 09:36:52 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006D_01C94C85.D9E3DC00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.20661 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_006D_01C94C85.D9E3DC00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >From a recent Mozilla discussion... Services like Skype already provide end-to-end encryption to hundreds of = millions of users without any need for a guide or so. S/MIME encryption OTOH is a dated off-line scheme requiring message = encryption and decryption, while still not addressing core issues such = as who is talking to who, although that becomes fairly irrelevant since = there are no users worth mentioning. It is in this context worth mentioning that governments in the EU are = creating WS*-based messaging frameworks that (within their own community = at least) offer transparent encryption and signatures. Due to the fact = that governments should not indulge in secret actions (excluding CIA = here), encryption at the service level is exactly what they want; i.e. = you should be able to see what has been exchanged based on logging. How can you trust a service? I don't have a conclusive answer to that = except that this is a fact, otherwise Microsoft Live, Google mail, and = hundreds of thousands of other "cloud computing" services wouldn't = exist. Another related issue is secure citizen-to-government communication. In = the EU, practically all states work with centralized mail-boxes on the = web to which you authenticate to. My own work FWIW, is very much = focused on these developments because they have proved to scale and are = in fact just government versions of Microsoft's and Google's stuff. Please go ahead with S/MIME but be aware that the odds that you succeed = are extremely low. If I had an interest in scalable secure end-to-end = messaging, I would start with a blank piece of paper and see what the = options are. In case you do, please send me the draft because I'm still = a little bit curious at least :-) Sincerely Anders Rundgren ------=_NextPart_000_006D_01C94C85.D9E3DC00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
From a recent Mozilla = discussion...
 
Services like Skype already provide = end-to-end=20 encryption to hundreds of millions of users without any need for a guide = or=20 so.
 
S/MIME encryption OTOH is a dated = off-line scheme=20 requiring message encryption and decryption, while still not addressing = core=20 issues such as who is talking to who, although that becomes fairly = irrelevant=20 since there are no users worth mentioning.
 
It is in this context worth mentioning = that=20 governments in the EU are creating WS*-based messaging frameworks that = (within=20 their own community at least) offer transparent encryption and=20 signatures.   Due to the fact that governments should not = indulge in=20 secret actions (excluding CIA here), encryption at the service level is = exactly=20 what they want; i.e. you should be able to see what has been exchanged = based on=20 logging.
 
How can you trust a service?  I = don't have a=20 conclusive answer to that except that this is a fact, otherwise = Microsoft=20 Live, Google mail, and hundreds of thousands of other "cloud = computing"=20 services wouldn't exist.
 
Another related issue is secure=20 citizen-to-government communication.  In the EU, practically all = states=20 work with centralized mail-boxes on the web to which you authenticate = to. =20 My own work FWIW, is very much focused on these developments because = they have=20 proved to scale and are in fact just government versions of Microsoft's = and=20 Google's stuff.
 
Please go ahead with S/MIME but be = aware that the=20 odds that you succeed are extremely low.   If I had an = interest in=20 scalable secure end-to-end messaging, I would start with a blank = piece of=20 paper and see what the options are.  In case you do, please send=20 me the draft because I'm still a little bit curious at least=20 :-)
 
Sincerely
Anders = Rundgren
------=_NextPart_000_006D_01C94C85.D9E3DC00-- 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 mAKJjOoY029097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2008 12:45: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 mAKJjOiG029096; Thu, 20 Nov 2008 12:45:24 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp101.biz.mail.mud.yahoo.com (smtp101.biz.mail.mud.yahoo.com [68.142.200.236]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mAKJjDIT029068 for ; Thu, 20 Nov 2008 12:45:23 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 45920 invoked from network); 20 Nov 2008 19:45:12 -0000 Received: from unknown (HELO Wylie) (turners@130.129.29.26 with login) by smtp101.biz.mail.mud.yahoo.com with SMTP; 20 Nov 2008 19:45:12 -0000 X-YMail-OSG: W4GEGooVM1lL2xKV2viPjF4bS.LhPbhHdlMV0z9FbGlDZcNa1_sRpJtqvewpgzglalzrqwKaZ4ZT6fS7hzzWbj7zO09ZNgTeLxIDHbvFfD.9ReGIBr7IewaLxrM5VYOJgzB_8P8DmAqTW_eXSfc1nnrNwIezFQCvMzbmt55J X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "secdir" Cc: Subject: SMIME WG summary Date: Thu, 20 Nov 2008 13:44:47 -0600 Organization: IECA, Inc. Message-ID: <6C0AE36C1E164AA5AF1A6EAAA3A08991@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AclLSHHdw4pey/R4Q1SH0WsjF38iLA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The SMIME WG did not meeting at IETF 73. The SMIME WG has 9 IDs. Here is the status of those IDs: In RFC Editors Queue: - draft-ietf-smime-multisig: Pinned on draft-ietf-smime-3850bis & draft-ietf-smime-3850bis IDs. - draft-ietf-smime-ibearch: In EDIT state. - draft-ietf-smime-bfibecms: In EDIT state. With AD (status: Passed IETF LC) - draft-ietf-smime-3850bis: Awaiting GEN-ART comments - draft-ietf-smime-3851bis: Addressed IETF LC comments. Will publish when GEN-ART comments on draft-ietf-smime-3850bis are addressed. With AD (status: In 2nd IETF LC): - draft-ietf-smime-sha2: No comments so far. With AD (status: Awaiting new ID from authors): - draft-ietf-smime-rfc3278-update: Addressing WG LC comments. New version published shortly after meeting. Expected to go to WG LC. - draft-ietf-smime-cms-rsa-kem: A new version was posted, but another is needed to address Steve Kent's SECDIR comments. With WG - draft-ietf-smime-new-asn1: This ID updates many/most of the ASN.1 modules in the S/MIME WG to the '02 ASN.1. The authors want reviewers. It is expected that the ID will be ready for WG LC in December '08. 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 mAEIXMth002666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Nov 2008 11:33: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 mAEIXMP6002665; Fri, 14 Nov 2008 11:33: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 smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mAEIXAXQ002650 for ; Fri, 14 Nov 2008 11:33:21 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 19528 invoked from network); 14 Nov 2008 18:33:10 -0000 Received: from unknown (HELO Wylie) (turners@96.241.7.41 with login) by smtp104.biz.mail.re2.yahoo.com with SMTP; 14 Nov 2008 18:33:10 -0000 X-YMail-OSG: nXSJSEsVM1mCmHfjO7KfIONDbCSHd4u0jqy729vcHQ4e6lbB0gW08SaRyMgU1wjsdey9xdrtYdUWARbe77a8eD5miX5gDxzJEL_BIl7xaX1MmbPDPYtdihPDYBo8.yPSzJHwuwWWUhF3O4EMvMWWvLi3B5yC0s1cwkZ9l4s_JlRKpXacAeI4NlwNa9IQ X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "=?iso-8859-1?Q?'Alfred_H=CEnes'?=" , References: <200811140050.BAA19456@TR-Sys.de> Subject: RE: draft-ietf-smime-3278bis-03 incremental review Date: Fri, 14 Nov 2008 13:32:53 -0500 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AclF9nJgcRuG/gDXSjGaTLFVj4BDLAAkNUyg In-Reply-To: <200811140050.BAA19456@TR-Sys.de> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alfred, I should have a version that incorporates all of you changes by the end = of next week. spt=20 >-----Original Message----- >From: owner-ietf-smime@mail.imc.org=20 >[mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Alfred H=CEnes >Sent: Thursday, November 13, 2008 7:51 PM >To: ietf-smime@imc.org >Subject: draft-ietf-smime-3278bis-03 incremental review > > >Folks, >I have performed another (incremental) review of > draft-ietf-smime-3278bis-03 >and I apologize that it could not be completed in time. >Nevertheless, I hope it will still be useful. > >The only significant proposal I have is based on the=20 >observation that the change information vs. RFC 3278 has grown=20 >to an extent that it better should be moved to the end of the=20 >document (new Appendix B ?). >The carefully collected information there should be kept in=20 >this detail for historical record, and to educate implementors=20 >tackling software updates, but it now seems to over-stress the=20 >basic character of an Introduction. > >Beyond that, I found a bunch of editorials that will be sent=20 >off-list (ASAP, I hope tomorrow), after a final cross-checking=20 >with Sean's summary posted on 6 Nov 2008 (to remove potential=20 >redundancy). > >My primary conclusion is that the draft should go ahead after=20 >the next minor polishing update to address the comments. > > >Sean and Dan: please still be patient for the details to come. > > >Kind regards, > Alfred H=CEnes. > >--=20 > >+------------------------+--------------------------------------------+ >| 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 | >+------------------------+--------------------------------------------+ > 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 mAEBdYQp078472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Nov 2008 04:39: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 mAEBdYoR078471; Fri, 14 Nov 2008 04:39: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 ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAEBdLjJ078430 for ; Fri, 14 Nov 2008 04:39:32 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 009DF2E; Fri, 14 Nov 2008 12:39:17 +0100 (CET) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2008111412391565:218695 ; Fri, 14 Nov 2008 12:39:15 +0100 Message-ID: <491D62A7.8090809@edelweb.fr> Date: Fri, 14 Nov 2008 12:36:07 +0100 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 Cc: iesg@ietf.org, ietf-smime@imc.org, turners@ieca.com Subject: Last Call: draft-ietf-smime-3851bis (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification) to Proposed Standard References: <20081030164211.D60EF3A684F@core3.amsl.com> <6A85CB8D97994AB496262EFF38FD178B@Wylie> <200811132100.mADL0f60037594@balder-227.proper.com> In-Reply-To: X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 11/14/2008 12:39:15 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 11/14/2008 12:39:16 PM, Serialize complete at 11/14/2008 12:39:16 PM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000108070309040400080706" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000108070309040400080706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Would it be possible to add a comment concerning the multipart/signed creation or better some section mulipart/signed parsing that a system should nicely treat a multipart/signed message that has more than two parts. It may be not the right doc, probably better in CMS. it happens that some firewalls add "disclaimers" as an additional body-part as soon as they see that the top level mime is multipart/* At least one well known user agent refuses to show such messages. TIA for consideration. Peter Sylvester --------------ms000108070309040400080706 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOhTCC BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggWVMIIDMKADAgECAgYKwoI0lJgwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDcwNjI4MTc0MDU0WhcNMTQwNTAyMTc0 MDU0WjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4GgMIGdMDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAfBgNV HSMEGDAWgBSo2SuP1LBnur1JXLwz/HdSEblnnTANBgkqhkiG9w0BAQUFAAOCAk4AUgtIR4Jh Ynyk939SM6X4YZPNYIgDio8Gp064P1MBILDgI/hzSwyxT5bb1qUQub+icXO9/5ufsDufr/ff 2gCzKMuo3hC26iey630PzHTvJgrTcEp9c92IZPt3UKeouqy+95Lz2r58dbfouKLZVwiKQ0jP 2c2U5tPWmzW4CAjFWUKRYlrhbt+tjzW8CAA0DHO1xrrzAuTyuGNKcH4LlLuVo7MbDPn/uLma 1fAVYvH2c6OTwGHJyKTQVveYw4UqgAhErJMFWJDKm+Q9h91mCzkjrA1Eu0nVDUTV1+dW6mNT DPLIq0qSdqP7iT2WcNzQVy/0PiXT2aaEH9lE2W1SSD6PnT8y+aqJTGjRMK1cl7VSJHxbq8U9 lIS+6eiV5VrogAa8X52pKF0u91i+/CBZ3e5Mi2/BwMrMN/mXA/ZwL3p+jZpnijpqnqdz8iCn qR9ExhR+BpN/b56RqEu7llLrcwOS44kjbubALjxe0+XutidWjt/6/tLYuM7rJ6Hk1EweFGVd kRejKogD3GzZ3gOAIF/D28VBJcTRcyF7OI/k/3jPD0gHUGN1uxk2Krz8SE9GEPvP/JehCBl/ FrQOCsEUmszi7Se0Vxr2k1P7icxT7L/AcWt/djIgp/vsQNurbi0+5+q7YS2b2bc1HchjsmaI cXy8ha5IGk4+F1qrHZsGqTm5M7TzZN6k0X2llMaozrtPzxNMC6uvf1uRvHYHf1x0Q0pdxTzZ PuuFw1PUlu6o5xPHbf3ZgC7ZNSDry13ZEXmlG2Re0u9WwEJJ1nYqlcDvNzGCAq4wggKqAgEB MGUwWzELMAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2Ug RWRlbFBLSTEgMB4GA1UEAxMXRWRlbFBLSSBFZGVsV2ViIFBlcnNHRU4CBgqvijKA3jAJBgUr DgMCGgUAoIIBnzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w ODExMTQxMTM2MDdaMCMGCSqGSIb3DQEJBDEWBBTTSDhAyDd5gascjzefTGI/bcIrMDBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB0BgkrBgEEAYI3EAQxZzBlMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wdgYLKoZIhvcNAQkQAgsxZ6Bl MFsxCzAJBgNVBAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVk ZWxQS0kxIDAeBgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wDQYJKoZI hvcNAQEBBQAEgYBSJC3iw+YmQwBLHKJNk9mJzSsIeG7I08+EiBmKaw8fdkZ7uU/Jg++TIJTN 0H2e6lTxAl8dZqh5DuqQmOwV/LQwnv1V4EPmcp2KbVEmbkrKFtDc/W4ufzmgXvo65sbUeBn7 AtMyl9RF4M3LoWuW6IMsufBd8qdMcqNcG+9AbyZSDQAAAAAAAA== --------------ms000108070309040400080706-- 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 mAE0qGZd047388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2008 17:52: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 mAE0qGY0047387; Thu, 13 Nov 2008 17:52: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 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 mAE0q3ZT047378 for ; Thu, 13 Nov 2008 17:52:15 -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 AA152433837; Fri, 14 Nov 2008 01:50:37 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id BAA19456; Fri, 14 Nov 2008 01:50:36 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200811140050.BAA19456@TR-Sys.de> Subject: draft-ietf-smime-3278bis-03 incremental review To: ietf-smime@imc.org Date: Fri, 14 Nov 2008 01:50:36 +0100 (MEZ) 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: Folks, I have performed another (incremental) review of draft-ietf-smime-3278bis-03 and I apologize that it could not be completed in time. Nevertheless, I hope it will still be useful. The only significant proposal I have is based on the observation that the change information vs. RFC 3278 has grown to an extent that it better should be moved to the end of the document (new Appendix B ?). The carefully collected information there should be kept in this detail for historical record, and to educate implementors tackling software updates, but it now seems to over-stress the basic character of an Introduction. Beyond that, I found a bunch of editorials that will be sent off-list (ASAP, I hope tomorrow), after a final cross-checking with Sean's summary posted on 6 Nov 2008 (to remove potential redundancy). My primary conclusion is that the draft should go ahead after the next minor polishing update to address the comments. Sean and Dan: please still be patient for the details to come. 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 | +------------------------+--------------------------------------------+ 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 mADLrAe7039892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2008 14:53: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 mADLrABV039891; Thu, 13 Nov 2008 14:53: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 smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mADLqwCZ039869 for ; Thu, 13 Nov 2008 14:53:09 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 90791 invoked from network); 13 Nov 2008 21:52:53 -0000 Received: from unknown (HELO Wylie) (turners@96.231.123.19 with login) by smtp107.biz.mail.re2.yahoo.com with SMTP; 13 Nov 2008 21:52:53 -0000 X-YMail-OSG: 1H.4_.UVM1nQ3PUr2KitvORwKCU6AE2dZktgawIDRgkDagAzErh9YGDgySBKzhKiaFYutlPHT2TtDg.b4VsbsAB0GilRY6W8ks08_5yuwZ2pSj1BWEF_xKh7ABLwLLLB0oajMiXPwp3Wf9BkwTmXgFOfMfX5r45YvMcMeLLvjDFB7ve3.I_u3r_r0PML X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "'Paul Hoffman'" , "'Russ Housley'" , , References: <20081030164211.D60EF3A684F@core3.amsl.com> <6A85CB8D97994AB496262EFF38FD178B@Wylie> <200811132100.mADL0f60037594@balder-227.proper.com> Subject: RE: Last Call: draft-ietf-smime-3851bis (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification) to Proposed Standard Date: Thu, 13 Nov 2008 16:52:39 -0500 Organization: IECA, Inc. Message-ID: <6DE25C581C4E42ED81E5E96388C19658@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AclF1GqQbAiaJSExT/+8S8a/2jE3qAAAdI+Q In-Reply-To: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >-----Original Message----- >From: Paul Hoffman [mailto:phoffman@imc.org] >Sent: Thursday, November 13, 2008 4:12 PM >To: Russ Housley; Turner, Sean P.; iesg@ietf.org; ietf-smime@imc.org >Subject: RE: Last Call: draft-ietf-smime-3851bis >(Secure/Multipurpose Internet Mail Extensions (S/MIME) Version >3.2 Message Specification) to Proposed Standard > >At 4:00 PM -0500 11/13/08, Russ Housley wrote: >>>Wouldn't it be much simpler to say that the key wrap >algorithm must be the same as the content encryption >algorithm? Yes, one *might* want a keywrap of greater strength >as you have above, but that forces implementations to have >tables of what "greater" means. Saying they need to be the >same is much more straight forward. >> >>The keysize could be the same, but the mode will probably be >different. One would not want to use AES Key Wrap for the content. > >Sorry, of course. I meant "same underlying encryption >function", not "same algorithm". Paul, Yes, it would be simpler. When DH ephemeral-static is used, a key wrap algorithm is also specified in the KeyEncryptionAlgorithmIdentifier [CMS]. The underlying encryption functions for the key wrap and content encryption algorithms ([CMSALG] and [CMSAES]) and the key sizes for the two algorithms MUST be the same (e.g., AES 128 key wrap algorithm with AES 128 content encryption algorithm). As AES 128 CBC is the mandatory to implement content encryption algorithm thus, when DH ephemeral-static is supported, AES-128 key wrap algorithm MUST also be supported. 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 mADLBjZB038133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2008 14:11: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 mADLBi2P038132; Thu, 13 Nov 2008 14:11:44 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mADLBa2o038112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2008 14:11:37 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200811132100.mADL0f60037594@balder-227.proper.com> References: <20081030164211.D60EF3A684F@core3.amsl.com> <6A85CB8D97994AB496262EFF38FD178B@Wylie> <200811132100.mADL0f60037594@balder-227.proper.com> Date: Thu, 13 Nov 2008 13:11:34 -0800 To: Russ Housley , "Turner, Sean P." , , From: Paul Hoffman Subject: RE: Last Call: draft-ietf-smime-3851bis (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification) to Proposed Standard Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 4:00 PM -0500 11/13/08, Russ Housley wrote: >>Wouldn't it be much simpler to say that the key wrap algorithm must be the same as the content encryption algorithm? Yes, one *might* want a keywrap of greater strength as you have above, but that forces implementations to have tables of what "greater" means. Saying they need to be the same is much more straight forward. > >The keysize could be the same, but the mode will probably be different. One would not want to use AES Key Wrap for the content. Sorry, of course. I meant "same underlying encryption function", not "same algorithm". 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 mADL0qfo037612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2008 14:00:52 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mADL0qPO037611; Thu, 13 Nov 2008 14:00:52 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mADL0fNw037593 for ; Thu, 13 Nov 2008 14:00:51 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200811132100.mADL0fNw037593@balder-227.proper.com> Received: (qmail 20543 invoked by uid 0); 13 Nov 2008 21:00:34 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 13 Nov 2008 21:00:34 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 13 Nov 2008 16:00:37 -0500 To: Paul Hoffman , "Turner, Sean P." , , From: Russ Housley Subject: RE: Last Call: draft-ietf-smime-3851bis (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification) to Proposed Standard In-Reply-To: References: <20081030164211.D60EF3A684F@core3.amsl.com> <6A85CB8D97994AB496262EFF38FD178B@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: > >One thing I noted is that to ensure interoperability of the SHOULD- for the > >DH ephemeral-static requirement we need to pick a MUST key wrap algorithm > >(note that E-S DH was a SHOULD in RFC 3851 but RFC 3851 did not include > >requirements for a key wrap algorithm). The text should not only indicate > >which key wrap algorithms to use but what kind of content encryption keys > >the algorithm is "good" for. I suggest adding the following text to Section > >2.3 right after the bullets (all of the references were already normative > >references): > > > >When DH ephemeral-static is used, a key wrap algorithm is also specified in > >the KeyEncryptionAlgorithmIdentifier [CMS]. When DH ephemeral-static is > >used with an AES content encryption algorithm (see Section 2.7), the key > >wrap algorithm MUST be an AES key wrap algorithm from [CMSAES]. When DH > >ephemeral-static is used with the Triple DES content encryption algorithm > >(see Section 2.7), the key wrap algorithm MUST be either Triple DES key wrap > >from [CMSALG] or one of the AES key wraps from [CMSAES]. The strength of > >the key wrap algorithm MUST be as strong as the content encryption > >algorithm: > > > >- The Triple-DES key wrap algorithm can be used with the Triple-DES content > > encryption algorithm, > >- The AES 128 key wrap algorithm can be used with The Triple-DES and AES 128 > > content encryption algorithms, > >- The AES 192 key wrap algorithm can be used with The Triple-DES, AES 128, > > and AES 192 content encryption algorithms, > >- The AES 256 key wrap algorithm can be used with The Triple-DES, AES 128, > > AES 192, and AES 256 content encryption algorithms. > >Wouldn't it be much simpler to say that the key wrap algorithm must >be the same as the content encryption algorithm? Yes, one *might* >want a keywrap of greater strength as you have above, but that >forces implementations to have tables of what "greater" means. >Saying they need to be the same is much more straight forward. The keysize could be the same, but the mode will probably be different. One would not want to use AES Key Wrap for the content. Russ 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 mADKjuHa036988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2008 13:45: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 mADKju5Y036986; Thu, 13 Nov 2008 13:45: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 [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mADKjm4r036974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2008 13:45:49 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <6A85CB8D97994AB496262EFF38FD178B@Wylie> References: <20081030164211.D60EF3A684F@core3.amsl.com> <6A85CB8D97994AB496262EFF38FD178B@Wylie> Date: Thu, 13 Nov 2008 12:45:46 -0800 To: "Turner, Sean P." , , From: Paul Hoffman Subject: RE: Last Call: draft-ietf-smime-3851bis (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification) to Proposed Standard Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 1:05 PM -0500 11/13/08, Turner, Sean P. wrote: >One thing I noted is that to ensure interoperability of the SHOULD- for the >DH ephemeral-static requirement we need to pick a MUST key wrap algorithm >(note that E-S DH was a SHOULD in RFC 3851 but RFC 3851 did not include >requirements for a key wrap algorithm). The text should not only indicate >which key wrap algorithms to use but what kind of content encryption keys >the algorithm is "good" for. I suggest adding the following text to Section >2.3 right after the bullets (all of the references were already normative >references): > >When DH ephemeral-static is used, a key wrap algorithm is also specified in >the KeyEncryptionAlgorithmIdentifier [CMS]. When DH ephemeral-static is >used with an AES content encryption algorithm (see Section 2.7), the key >wrap algorithm MUST be an AES key wrap algorithm from [CMSAES]. When DH >ephemeral-static is used with the Triple DES content encryption algorithm >(see Section 2.7), the key wrap algorithm MUST be either Triple DES key wrap >from [CMSALG] or one of the AES key wraps from [CMSAES]. The strength of >the key wrap algorithm MUST be as strong as the content encryption >algorithm: > >- The Triple-DES key wrap algorithm can be used with the Triple-DES content > encryption algorithm, >- The AES 128 key wrap algorithm can be used with The Triple-DES and AES 128 > content encryption algorithms, >- The AES 192 key wrap algorithm can be used with The Triple-DES, AES 128, > and AES 192 content encryption algorithms, >- The AES 256 key wrap algorithm can be used with The Triple-DES, AES 128, > AES 192, and AES 256 content encryption algorithms. Wouldn't it be much simpler to say that the key wrap algorithm must be the same as the content encryption algorithm? Yes, one *might* want a keywrap of greater strength as you have above, but that forces implementations to have tables of what "greater" means. Saying they need to be the same is much more straight forward. 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 mADI5S64023132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2008 11:05: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 mADI5S91023131; Thu, 13 Nov 2008 11:05: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 mADI5HHj023096 for ; Thu, 13 Nov 2008 11:05:27 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 76522 invoked from network); 13 Nov 2008 18:05:16 -0000 Received: from unknown (HELO Wylie) (turners@96.231.123.19 with login) by smtp109.biz.mail.re2.yahoo.com with SMTP; 13 Nov 2008 18:05:16 -0000 X-YMail-OSG: Ri.tU_gVM1m_idOWwjSdnYUy2kTDA3tdHEKziwqC7o5.8El79eiQasEt_7tHJ9H7AGpGPlGCCIfZuqlmwkVdTAkqs51YuwO.euS08PcIgI6RUnU126tvDKJO7slqEAKjKaD_ZkfSiDyRbtueS0ELKIKHJF8d8cZktQslvJgPMhiVobcHkDzvYRbzgwGW X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: , References: <20081030164211.D60EF3A684F@core3.amsl.com> Subject: RE: Last Call: draft-ietf-smime-3851bis (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification) to Proposed Standard Date: Thu, 13 Nov 2008 13:05:02 -0500 Organization: IECA, Inc. Message-ID: <6A85CB8D97994AB496262EFF38FD178B@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: Ack6rtPdEuque2DLR8yPNyX5TMydiwLCQuhA In-Reply-To: <20081030164211.D60EF3A684F@core3.amsl.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: One thing I noted is that to ensure interoperability of the SHOULD- for the DH ephemeral-static requirement we need to pick a MUST key wrap algorithm (note that E-S DH was a SHOULD in RFC 3851 but RFC 3851 did not include requirements for a key wrap algorithm). The text should not only indicate which key wrap algorithms to use but what kind of content encryption keys the algorithm is "good" for. I suggest adding the following text to Section 2.3 right after the bullets (all of the references were already normative references): When DH ephemeral-static is used, a key wrap algorithm is also specified in the KeyEncryptionAlgorithmIdentifier [CMS]. When DH ephemeral-static is used with an AES content encryption algorithm (see Section 2.7), the key wrap algorithm MUST be an AES key wrap algorithm from [CMSAES]. When DH ephemeral-static is used with the Triple DES content encryption algorithm (see Section 2.7), the key wrap algorithm MUST be either Triple DES key wrap from [CMSALG] or one of the AES key wraps from [CMSAES]. The strength of the key wrap algorithm MUST be as strong as the content encryption algorithm: - The Triple-DES key wrap algorithm can be used with the Triple-DES content encryption algorithm, - The AES 128 key wrap algorithm can be used with The Triple-DES and AES 128 content encryption algorithms, - The AES 192 key wrap algorithm can be used with The Triple-DES, AES 128, and AES 192 content encryption algorithms, - The AES 256 key wrap algorithm can be used with The Triple-DES, AES 128, AES 192, and AES 256 content encryption algorithms. spt >-----Original Message----- >From: ietf-announce-bounces@ietf.org >[mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG >Sent: Thursday, October 30, 2008 12:42 PM >To: IETF-Announce >Cc: ietf-smime@imc.org >Subject: Last Call: draft-ietf-smime-3851bis >(Secure/Multipurpose Internet Mail Extensions (S/MIME) Version >3.2 Message Specification) to Proposed Standard > >The IESG has received a request from the S/MIME Mail Security >WG (smime) to consider the following document: > >- 'Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 > Message Specification ' > as a Proposed Standard > >The IESG plans to make a decision in the next few weeks, and >solicits final comments on this action. > >In particular, the IESG solicits comments on the cryptographic >strength requirements specified in section 4.1 through 4.5, >and the following statement from Section 6, Security Considerations: > > "Today, 512-bit RSA, DSA and DH keys are considered by many experts > to be cryptographically insecure." > >These sections allow the continued use of RSA, DSA, and DH key >lengths between 512 and 1024 bits. Given that other >organizations are moving to a minimum key length of 2048 bits, >the IESG wishes to verify IETF consensus for the cryptographic >minimums in this document. > >Please send substantive comments to the >ietf@ietf.org mailing lists by 2008-11-13. Exceptionally, >comments may be sent to iesg@ietf.org instead. In either case, >please retain the beginning of the Subject line to allow >automated sorting. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-smime-3851bis-08.txt > > >IESG discussion can be tracked via >https://datatracker.ietf.org/public/pidtracker.cgi?command=view >_id&dTag=16577&rfc_flag=0 > >_______________________________________________ >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 mAAITw0L077518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Nov 2008 11:29: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 mAAITwkJ077517; Mon, 10 Nov 2008 11:29:58 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAAITwYM077510 for ; Mon, 10 Nov 2008 11:29:58 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 34F5928C137; Mon, 10 Nov 2008 10:30:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-smime@imc.org Subject: I-D ACTION:draft-ietf-smime-cms-rsa-kem-06.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081110183001.34F5928C137@core3.amsl.com> Date: Mon, 10 Nov 2008 10:30:01 -0800 (PST) Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Use of the RSA-KEM Key Transport Algorithm in CMS Author(s) : J. Randall, B. Kaliski Filename : draft-ietf-smime-cms-rsa-kem-06.txt Pages : 23 Date : 2008-11-10 The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) mechanism for transporting keying data to a recipient using the recipient's RSA public key. This document specifies the conventions for using the RSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax (CMS). The ASN.1 syntax is aligned with ANS X9.44 and ISO/IEC 18033-2. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-rsa-kem-06.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-cms-rsa-kem-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-10102636.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 mAAI3Tfw073759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Nov 2008 11:03:29 -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 mAAI3TQr073758; Mon, 10 Nov 2008 11:03:29 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAAI3SCQ073751 for ; Mon, 10 Nov 2008 11:03:29 -0700 (MST) (envelope-from wwwrun@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 30) id 6512128C0F6; Mon, 10 Nov 2008 10:03:31 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , smime mailing list , smime chair Subject: Document Action: 'Using the Boneh-Franklin and Boneh-Boyen identity-based Encryption Algorithms with the Cryptographic Message Syntax (CMS)' to Informational RFC Message-Id: <20081110180331.6512128C0F6@core3.amsl.com> Date: Mon, 10 Nov 2008 10:03:31 -0800 (PST) Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the following document: - 'Using the Boneh-Franklin and Boneh-Boyen identity-based Encryption Algorithms with the Cryptographic Message Syntax (CMS) ' as an Informational RFC 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-bfibecms-10.txt Technical Summary This document describes the conventions for using the Boneh-Franklin (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in the Cryptographic Message Syntax (CMS) to encrypt content-encryption keys. Object identifiers and the convention for encoding a recipient's identity are also defined. Working Group Summary This document is a product of the S/MIME Working Group. There was very little public discussion about this draft. During WG last call comments were raised and addressed, and after last call some nits were addressed. Protocol Quality Tim Polk reviewed this document for the IESG. At least one implementation of this protocol exists; additional vendors have not expressed an intention to implement this protocol. Note to RFC Editor Please note that Intended Status should be Informational, not Standards Track. (The document header asserted Standards track.) 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 mAAI26fY073604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Nov 2008 11:02:06 -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 mAAI26tk073603; Mon, 10 Nov 2008 11:02:06 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAAI250A073597 for ; Mon, 10 Nov 2008 11:02:05 -0700 (MST) (envelope-from wwwrun@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 30) id C55BC28C113; Mon, 10 Nov 2008 10:02:07 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , smime mailing list , smime chair Subject: Document Action: 'Identity-based Encryption Architecture and Supporting Data Structures' to Informational RFC Message-Id: <20081110180207.C55BC28C113@core3.amsl.com> Date: Mon, 10 Nov 2008 10:02:07 -0800 (PST) Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the following document: - 'Identity-based Encryption Architecture and Supporting Data Structures ' as an Informational RFC 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-ibearch-09.txt Technical Summary This document describes the security architecture required to implement identity-based encryption, a public-key encryption technology that uses a user's identity to generate their public key. Working Group Summary This document is a product of the S/MIME Working Group. There was very little public discussion about this draft. During WG last call comments were raised and addressed, and after last call some nits were addressed. Protocol Quality Tim Polk reviewed this document for the IESG. At least one implementation exists; no additional vendors have announced implementation plans. Note to RFC Editor (1) Please note that Intended Status should be Informational, not Standards Track. (The document header asserted Standards track.) (2) Please make the following substitution in section 8.2 OLD BEGIN algorithmOID ibeIdentityInfo ibeAuthData bodyTags END NEW Identity-based Encryption

Namespace for Identity-based Encryption

urn:ietf:params:xml:ns:ibe

RFCXXXX.

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 mA7GmgH2019673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Nov 2008 09:48: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 mA7GmgMr019671; Fri, 7 Nov 2008 09:48: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 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 mA7GmUus019649 for ; Fri, 7 Nov 2008 09:48:41 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 98346 invoked from network); 7 Nov 2008 16:48:30 -0000 Received: from unknown (HELO Wylie) (turners@96.241.99.222 with login) by smtp106.biz.mail.re2.yahoo.com with SMTP; 7 Nov 2008 16:48:29 -0000 X-YMail-OSG: 3L0jE6QVM1myMvb6lTgCaGQnGM_X_PQyXCbZtp6qpZ7xb730n4.53nzwP5Sf1qUUR.BhpGJP34HXhEnaTRor8MLPAl9bK3Ue_HRa6yJg2lDs.k75MNiEJ843wlcPOOtegURvkcQTMjRlzPTK61u8FQcZrrhLD7WIO5BcKDgCErx0jGTLsDF8vYpr6XmyvQ-- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: Subject: IPR Disclosure for RFC 2633, 3278, 3850, 3851, and IDs draft-ietf-smime-3851bis, draft-ietf-smime-multisig, draft-ietf-smime-sha2, draft-ietf-smime-3278bis Date: Fri, 7 Nov 2008 11:48:13 -0500 Organization: IECA, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AclA+J/qtASEvUxISiat67dsqXy+sA== Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Note that Certicom has submitted an IPR disclosure that addresses a number of RFCs and IDs in the S/MIME WG: https://datatracker.ietf.org/ipr/1004/ It updates IPR Disclosure #750. 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 mA6DB38l091026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 06:11: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 mA6DB3GQ091025; Thu, 6 Nov 2008 06:11: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 smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mA6DApJU090996 for ; Thu, 6 Nov 2008 06:11:02 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 60068 invoked from network); 6 Nov 2008 13:10:51 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@71.191.15.124 with login) by smtp104.biz.mail.re2.yahoo.com with SMTP; 6 Nov 2008 13:10:51 -0000 X-YMail-OSG: d9ov4K0VM1mGlBULmGjbYMWhW1X5_w4Q7PTaD_j1LinDKFtrc23HKJRKlVTFbwWpt5vlhnqcOfa4OTa2Sx3BvBlbLnfQWYJ3RH8hStZNuG2J0TjvbebX2MFOj_KERsZXVXJs X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: Subject: draft-ietf-smime-3278bis: KDF Date: Thu, 6 Nov 2008 08:10:38 -0500 Organization: IECA, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AclAEQ/wwMnEveNoRf2rlFDnakqJLA== Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: One of the comments raised during WG LC noted the difference between the RFC 3278 and NIST SP800-56A KDFs. RFC 3278 was hash(Z || counter || otherinfo) and SP800-56A is hash(counter || Z || otherinfo). I think we need to maintain backwards compatibility and *not* use the NIST SP800-56A KDF and revert back to the KDF used in RFC 3278. Do others agree/disagree? If we revert back, we'd make the following changes: #1 - the last two paragraphs in Section 7.2 will refer to Section 3.6.1 of [SEC1] instead of 6.3.2 of [SP800-56A]. I don't want people to miss this so... #2 - We should amend the two sentences in 3.1.2 and 3.1.3 to say: The sending/receiving agent performs the key agreement operation of the Elliptic Curve Diffie-Hellman Scheme specified in [SP800-56A] or [SEC1]; in either case, use the KDF defined in Section 3.6.1 of [SEC1]. #3 - We should amend the two sentences in 3.2.2 and 3.1.3 to say: The sending/receiving agent then performs the key deployment and key agreement operations of the Elliptic Curve DH/MQV Scheme specified in [SP800-56A], but uses the KDF defined in Section 3.6.1 of [SEC1]. #4 - We should add a new Section 7.1.6 titled Key Derivation Algorithm. The section will have one sentence: "The KDF used in this document is as specified in 3.6.1 of [SEC1]." 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 mA6D85H6090765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 06:08:05 -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 mA6D85do090764; Thu, 6 Nov 2008 06:08: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 smtp108.biz.mail.re2.yahoo.com (smtp108.biz.mail.re2.yahoo.com [206.190.52.47]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mA6D7s3u090749 for ; Thu, 6 Nov 2008 06:08:04 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 29425 invoked from network); 6 Nov 2008 13:07:53 -0000 Received: from unknown (HELO Wylie) (turners@71.191.15.124 with login) by smtp108.biz.mail.re2.yahoo.com with SMTP; 6 Nov 2008 13:07:53 -0000 X-YMail-OSG: c_ifIaYVM1mQZHPlVy9deWzcUE.p88Kjt_eTg70KyOt8vK3JqR.Syw2l5_y2IeU6sHRp8QmEJMWvWFiyU2iJt3Vx.GUaXRSgyLOtxon5eDysu0MV3Gwxjcneb2_rdCZPXAuO X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: Subject: RE: WG Last Call: draft-ietf-smime-3278bis-03 Date: Thu, 6 Nov 2008 08:07:39 -0500 Organization: IECA, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: Ack0ivxP1a3c739GTlK9ds19310tKgKLYDUwAADPIcAAAABkgA== Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The WG LC closes today. Below is a list of comments I've received so far. ------- Section 3.1 (E-S ECDH), in the third paragraph, it states that the originatorInfo field MAY include the certificate(s) for the EC public key(s) used in the formation of the pairwise key. The originatorInfo field only contain certs and CRLs related to the originator (and not the recipient). With ephemeral-static, the originaltor does not have a certified public key. spt> I deleted the last two sentences from the paragraph. Section 3.1.1 says that the permitted digest algorithms for use with ECDH were expanded to SHA-1, SHA-224 etc. Note that this is not described in 3.1.1 (which deals with enveloped data). Also, "NULL to absent or ECPoint" should be "NULL to absent or ECParameters". spt> I moved the discussion about the algorithm changes to the bullet describing the Section 5 changes. That line should refer to the hash algorithm used in the KDF and then it would apply to EnvelopedData. In that same area (comments for section 3.1.1) the last word is ECPoint. Shouldn't this be ECParameters? spt> Yes in Section 1.2 the bullet for 3.1.1 should refer to ECParameters not ECPoint. Section 3.1.1 the section on keyEncryption Algorithm says that it must contain the "key encryption algorithm" object identifier (see section 7.1). Section 7.1 does not include anything with that designator. spt> This actually made me go and make sure all the pointers to 7.1 to make sure they pointed to the new sub-sections. It should point to 7.1.4 which is the key agreement information section. I change the 1st sentence to say "keyEncryptionAlgorithm MUST contain the key encryption algorithm, which in this case is a key agreement algorithm, object identifier (see Section 7.1.4)." I also added a pointer to 7.1.5 in the sentence that describes the KeyWrapAlgorithm field. Section 3.1.2 at the end "a shared secret bit string 'K' which is used as the pairwise key-encryption key" is misleading. The shared secret is not the KEK. The shared secret is sent with other info through a KDF to form the KEK. This sentence is replicated in other places in this draft, for example, Section 3.1.3, section 3.2.2, 3.2.3. spt> The key deployment and key agreement operations result in the ephemeral and shared secret. The "Z", which is used to derive the "K", is generated during the key agreement operation. In NIST SP800-56A it's Section 6.2.2 Step 4 (same is true of SEC1 process). Section 3.2.2 - last paragraph talking about multiple layers. You have one message with one recipient and nested layers (eg, encrypted signed encrypted message). This says that you can use the same originator ephemeral key for all of these nested layers? If so, don't you have to ensure that an addedukm field is added at each layer and they are different or does it not matter if you have the same KEK at each layer? Further, NIST SP800-56A says "Each call to the KDF requires a freshly computed shared secret, and this shared secret shall be zeroized imediately following its use". So doesn't that mean you need a new ephmeral for each layer? spt> I'll address this in a seperate email. Section 3.2.3 "....checks that the domain parameters are the same as the recipient's domain parameters" Should recipient be originator instead? spt> I modified the sentence as follows so it's clear the recipient is check that the originator's and recipient's domain parameters are the same: "The receiving agent then retrieves the static and ephemeral EC public keys of the originator, from the originator and ukm fields as described in Section 3.2.1, and its static EC public key identified in the rid field and checks that the ***originator's*** domain parameters are the same as the recipient's domain parameters." Section 4.2 "originatorInfo field MAY include the cert(s) for the EC public key(s)" If originatorInfo only applies to the originator and this is C(1,2, ECC MQV) then don't we have just one static key (ie, you would state EC public key -- not plural) spt> I'll remove the "s". Section 5: "The 1st paragraph was modified to require both SignedData...." Should this be recommend? Also, this comment is for Section 6 not section 5. spt> I changed it to recommended and I merge the two bullets. Section 6: talks about ecdsa-with-SHA* having NULL parameters (to be consistent with RFC3278, section 7). However, this seems to contradict 3851bis, section 2.5.2 , last paragraph. Same thing in the Note in section 6. spt> Yes I ought to change these. I changed the note so that it only applies to SHA-1 and changed NULL to absent in the two ASN.1 modules. Comments for Section 7.1 Should you include "key wrap" in the part about adding subsections? spt> Added it in Section 1.2. Section 7.2 last para listing the KDF in SP800-56A. This KDF is dramatically different from the one in RFC3278. The "otherinfo" in SP800-56A is much more complex and I don't know what values the AlgorithmId, PartyUInfo, PartyVInfo would take by reading this draft. Also, this one does hash(counter || Z || otherinfo); the old kdf did hash(Z || counter || otherinfo) spt> I will address this is in a separate email. Reference: FIPS 180-3 is no longer a draft - it's official as of October 2008. spt> Fixed. Section E.8 of X9.62 says that CMS SignedData represents signatures as a bit string. Section 2.1.1 says "signature MUST contain the DER encoding (as an octet string) " These two are in conflict, but I think that Section 2.1.1 is correct. spt> Glad we got it right ;) Any chance somebody can take this to ANSI? TYPOS Section 1.2 change FIPP to FIPS Section 1.2 -- Section 5. Need an "in" in this sentence: "...to be present in certificates". Section 3 : need a "to" in "security due to the originator's" section 7.1.2: last para. need a " ' " in recipient's ECParameters. section 7.1.3: need to make field plural in first sentence section 7.2: should there be a "." in ephemeralPublicKey.publicKey (wasn't sure) section 8: need to change RECOMMEND to RECOMMENDED Section 9: need to make random number plural spt> all fixed except 7.2 where we left the period. A subfield of originatorPublicKey is publicKey and that's where the key goes. 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 mA5HgmKH009518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Nov 2008 10:42: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 mA5HgmLj009517; Wed, 5 Nov 2008 10:42: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 smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mA5HgbjL009488 for ; Wed, 5 Nov 2008 10:42:47 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 49195 invoked from network); 5 Nov 2008 17:42:37 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@71.191.15.124 with login) by smtp104.biz.mail.re2.yahoo.com with SMTP; 5 Nov 2008 17:42:36 -0000 X-YMail-OSG: ZlNf8fgVM1kIUIXL_Y5Nl_Es3DJj.QL2hut3yKBzsVjqS3wmJHM1lbd97WWgRi23L2IOL4LhX0X2cp7wqZ9KZ4qpsbs0s_PIcIXh81YhTy20WPccCLcjTdW7setHulqaPaFVYD6Vbj_MTo1EAwoxLgRh8cr5vrRzH2RAXxcz5EEoaw7YnwlLoUG4oPXNtg-- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "'Russ Housley'" , "'zhaohui cheng'" Cc: References: <200811032328.mA3NSLQO009097@balder-227.proper.com> Subject: RE: Consistence question of CMS Date: Wed, 5 Nov 2008 12:42:25 -0500 Organization: IECA, Inc. Message-ID: <05F0571B98CF4ACC861A55AA8CCE452D@Wylie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D9_01C93F43.F5064F80" X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ack+Fo/TgP3es6qFSN6IK6My4PgIjQBVwi5Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <200811032328.mA3NSLQO009097@balder-227.proper.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_00D9_01C93F43.F5064F80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Russ, Yes - I agree. RFC 2630 also supports this: If originatorInfo is absent, all of the RecipientInfo structures are version 0, and unprotectedAttrs is absent, then version shall be 0. Also originatorInfo and unprotectedAttributes aren't defined in RFC 2315 so to be version 0 these fields can't be present. To be version 0, RecipientInfos must also have a version = -0, according to RFC 3215. spt _____ From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Russ Housley Sent: Monday, November 03, 2008 6:21 PM To: zhaohui cheng Cc: ietf-smime@imc.org Subject: Re: Consistence question of CMS I think this is an error. I think the end of the RFC 3852 algorithm should be: IF (originatorInfo is absent) AND (unprotectedAttrs is absent) AND (all RecipientInfo structures are version 0) THEN version is 0 ELSE version is 2 Do others agree? Russ At 01:04 AM 11/3/2008, zhaohui cheng wrote: Hi Russell, I have a question regarding the consistence between RFC 3852 and RFC 3369. For the version of EnvelopedData, the rules in RFC 3369 and RFC 3852 are defined as follows ---RFC 3369 IF ((originatorInfo is present) AND (any version 2 attribute certificates are present)) OR (any RecipientInfo structures include pwri) OR (any RecipientInfo structures include ori) THEN version is 3 ELSE IF (originatorInfo is present) OR (unprotectedAttrs is present) OR (any RecipientInfo structures are a version other than 0) THEN version is 2 ELSE version is 0 --RFC 3852 IF (originatorInfo is present) AND ((any certificates with a type of other are present) OR (any crls with a type of other are present)) THEN version is 4 ELSE IF ((originatorInfo is present) AND (any version 2 attribute certificates are present)) OR (any RecipientInfo structures include pwri) OR (any RecipientInfo structures include ori) THEN version is 3 ELSE IF (originatorInfo is absent) OR (unprotectedAttrs is absent) OR (all RecipientInfo structures are version 0) THEN version is 0 ELSE version is 2 It appears the two sets of rules are not consistent. In particular, if originatorInfo is absent but one RecipientInfo structure has version other than 0, then according to RFC 3369, the version should be 2, but 0 in 3852. Is this rule deliberately changed in 3852 or just typos? Kind regards, Michael Cheng ------=_NextPart_000_00D9_01C93F43.F5064F80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Russ,

Yes - I agree. RFC 2630 also supports this:

If originatorInfo is absent, all of the RecipientInfo structures are = version=20 0, and unprotectedAttrs is absent, then version shall be 0.

Also originatorInfo and unprotectedAttributes aren't defined in RFC = 2315 so=20 to be version 0 these fields can't be present. To be version 0, = RecipientInfos=20 must also have a version =3D -0, according to RFC 3215.

spt



From: = owner-ietf-smime@mail.imc.org=20 [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Russ=20 Housley
Sent: Monday, November 03, 2008 6:21 = PM
To:=20 zhaohui cheng
Cc: ietf-smime@imc.org
Subject: Re:=20 Consistence question of CMS

I think this is an error.  I think the end of the RFC = 3852=20 algorithm should=20 = be:

          &n= bsp;   =20 IF (originatorInfo is absent)=20 = AND
           =       =20 (unprotectedAttrs is absent)=20 = AND
           =       =20 (all RecipientInfo structures are version=20 = 0)
           &= nbsp;  =20 THEN version is=20 = 0
           &n= bsp;  =20 ELSE version is 2

Do others agree?

Russ


At = 01:04 AM=20 11/3/2008, zhaohui cheng wrote:

Hi Russell,

I have a question = regarding=20 the consistence between RFC 3852 and RFC 3369.

For the = version of=20 EnvelopedData, the rules in RFC 3369 and  RFC 3852  are = defined as=20 follows

 ---RFC=20 3369

         IF=20 ((originatorInfo is present)=20 = AND
           =  =20 (any version 2 attribute certificates are present))=20 = OR
            = (any RecipientInfo structures include pwri)=20 = OR
            = (any RecipientInfo structures include=20 ori)
         THEN = version is=20 3
        =20 = ELSE
           = ;=20 IF (originatorInfo is present)=20 = OR
           &= nbsp;  =20 (unprotectedAttrs is present)=20 = OR
           &= nbsp;  =20 (any RecipientInfo structures are a version other than=20 = 0)
            = THEN version is=20 = 2
            = ELSE=20 version is 0

 

--RFC 3852 =20
         IF = (originatorInfo is=20 present)=20 = AND
           = =20 ((any certificates with a type of other are present)=20 = OR
            = (any crls with a type of other are=20 present))
         THEN = version=20 is 4
        =20 = ELSE
           = ;=20 IF ((originatorInfo is present)=20 = AND
           =    =20 (any version 2 attribute certificates are present))=20 = OR
           &= nbsp;  =20 (any RecipientInfo structures include pwri)=20 = OR
           &= nbsp;  =20 (any RecipientInfo structures include=20 = ori)
           = ;=20 THEN version is=20 = 3
           =20 = ELSE
           = ;   =20 IF (originatorInfo is absent)=20 = OR
           &= nbsp;     =20 (unprotectedAttrs is absent)=20 = OR
           &= nbsp;     =20 (all RecipientInfo structures are version=20 = 0)
           &= nbsp;  =20 THEN version is=20 = 0
           &n= bsp;  =20 ELSE version is 2

It appears the two sets of rules are not=20 consistent.  In particular, if originatorInfo is absent but one =

RecipientInfo structure has version other than 0, then = according to=20 RFC 3369, the version should be 2, but 0 in 3852. Is this rule = deliberately=20 changed in 3852 or just typos?

Kind regards,

Michael=20 Cheng
------=_NextPart_000_00D9_01C93F43.F5064F80-- 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 mA5H9YbW007016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Nov 2008 10:09: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 mA5H9YL2007015; Wed, 5 Nov 2008 10:09: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 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 mA5H9LpT007000 for ; Wed, 5 Nov 2008 10:09:33 -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 AA104314877; Wed, 5 Nov 2008 18:07:57 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id SAA01398; Wed, 5 Nov 2008 18:07:56 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200811051707.SAA01398@TR-Sys.de> Subject: Re: [ietf-smime] Consistence question of CMS To: housley@vigilsec.com Date: Wed, 5 Nov 2008 18:07:55 +0100 (MEZ) Cc: ietf-smime@imc.org 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: At Mon, 03 Nov 2008 18:21:25 -0500 , Russ Housley wrote: > I think this is an error. > I think the end of the RFC 3852 algorithm should be: > > IF (originatorInfo is absent) AND > (unprotectedAttrs is absent) AND > (all RecipientInfo structures are version 0) > THEN version is 0 > ELSE version is 2 > > Do others agree? > > Russ Yes. I agree. But that's by far an easy job, more of re-inventing the wheel: Looking up my printed copy of RFC 3852, I found a bold question mark on page 18, vis-a-vis of that algorithm, and an exclamation mark pointing out the diff from 3369. Sigh -- admittedly I had to recognize that apparently I never had found the time to report errata for that RFC ... :-) But *you* did, Russ! ( on 2005-01-22 ) Folks, please look up the result of Russ' error report at: 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 | +------------------------+--------------------------------------------+ 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 mA3NSWRU009118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Nov 2008 16:28: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 mA3NSWEs009117; Mon, 3 Nov 2008 16:28: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 woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mA3NSLQO009097 for ; Mon, 3 Nov 2008 16:28:32 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200811032328.mA3NSLQO009097@balder-227.proper.com> Received: (qmail 12059 invoked by uid 0); 3 Nov 2008 23:28:13 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 3 Nov 2008 23:28:13 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 03 Nov 2008 18:21:25 -0500 To: zhaohui cheng From: Russ Housley Subject: Re: Consistence question of CMS Cc: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think this is an error.  I think the end of the RFC 3852 algorithm should be:

               IF (originatorInfo is absent) AND
                  (unprotectedAttrs is absent) AND
                  (all RecipientInfo structures are version 0)
               THEN version is 0
               ELSE version is 2

Do others agree?

Russ


At 01:04 AM 11/3/2008, zhaohui cheng wrote:

Hi Russell,

I have a question regarding the consistence between RFC 3852 and RFC 3369.

For the version of EnvelopedData, the rules in RFC 3369 and  RFC 3852  are defined as follows

 ---RFC 3369

         IF ((originatorInfo is present) AND
             (any version 2 attribute certificates are present)) OR
            (any RecipientInfo structures include pwri) OR
            (any RecipientInfo structures include ori)
         THEN version is 3
         ELSE
            IF (originatorInfo is present) OR
               (unprotectedAttrs is present) OR
               (any RecipientInfo structures are a version other than 0)
            THEN version is 2
            ELSE version is 0

 

--RFC 3852 
         IF (originatorInfo is present) AND
            ((any certificates with a type of other are present) OR
            (any crls with a type of other are present))
         THEN version is 4
         ELSE
            IF ((originatorInfo is present) AND
               (any version 2 attribute certificates are present)) OR
               (any RecipientInfo structures include pwri) OR
               (any RecipientInfo structures include ori)
            THEN version is 3
            ELSE
               IF (originatorInfo is absent) OR
                  (unprotectedAttrs is absent) OR
                  (all RecipientInfo structures are version 0)
               THEN version is 0
               ELSE version is 2

It appears the two sets of rules are not consistent.  In particular, if originatorInfo is absent but one

RecipientInfo structure has version other than 0, then according to RFC 3369, the version should be 2, but 0 in 3852. Is this rule deliberately changed in 3852 or just typos?

Kind regards,

Michael Cheng