Document Action: Preventing the Million Message Attack on CMS to Informational
The IESG <iesg-secretary@ietf.org> Mon, 29 October 2001 21:58 UTC
Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28513 for <smime-archive@odin.ietf.org>; Mon, 29 Oct 2001 16:58:31 -0500 (EST)
Received: by above.proper.com (8.11.6/8.11.3) id f9TLQrI15149 for ietf-smime-bks; Mon, 29 Oct 2001 13:26:53 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9TLQm815143 for <ietf-smime@imc.org>; Mon, 29 Oct 2001 13:26:52 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27537; Mon, 29 Oct 2001 16:26:44 -0500 (EST)
Message-Id: <200110292126.QAA27537@ietf.org>
To: IETF-Announce:;
Cc: RFC Editor <rfc-editor@isi.edu>, Internet Architecture Board <iab@isi.edu>, ietf-smime@imc.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Document Action: Preventing the Million Message Attack on CMS to Informational
Date: Mon, 29 Oct 2001 16:26:44 -0500
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>
The IESG has approved the Internet-Draft 'Preventing the Million Message Attack on CMS' <draft-ietf-smime-pkcs1-01.txt> as a Informational. This document is the product of the S/MIME Mail Security Working Group. The IESG contact persons are Jeffrey Schiller and Marcus Leech. Received: by above.proper.com (8.11.6/8.11.3) id f9TLQrI15149 for ietf-smime-bks; Mon, 29 Oct 2001 13:26:53 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9TLQm815143 for <ietf-smime@imc.org>; Mon, 29 Oct 2001 13:26:52 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27537; Mon, 29 Oct 2001 16:26:44 -0500 (EST) Message-Id: <200110292126.QAA27537@ietf.org> To: IETF-Announce: ; Cc: RFC Editor <rfc-editor@isi.edu>, Internet Architecture Board <iab@isi.edu>, ietf-smime@imc.org From: The IESG <iesg-secretary@ietf.org> Subject: Document Action: Preventing the Million Message Attack on CMS to Informational Date: Mon, 29 Oct 2001 16:26:44 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> The IESG has approved the Internet-Draft 'Preventing the Million Message Attack on CMS' <draft-ietf-smime-pkcs1-01.txt> as a Informational. This document is the product of the S/MIME Mail Security Working Group. The IESG contact persons are Jeffrey Schiller and Marcus Leech. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9TKu0F14449 for ietf-smime-bks; Mon, 29 Oct 2001 12:56:00 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9TKtx814445 for <ietf-smime@imc.org>; Mon, 29 Oct 2001 12:55:59 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26686; Mon, 29 Oct 2001 15:55:55 -0500 (EST) Message-Id: <200110292055.PAA26686@ietf.org> To: IETF-Announce: ; Cc: RFC Editor <rfc-editor@isi.edu>, Internet Architecture Board <iab@isi.edu>, ietf-smime@imc.org From: The IESG <iesg-secretary@ietf.org> Subject: Document Action: Triple-DES and RC2 Key Wrapping to Informational Date: Mon, 29 Oct 2001 15:55:55 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> The IESG has approved the Internet-Draft 'Triple-DES and RC2 Key Wrapping' <draft-ietf-smime-key-wrap-01.txt> as an Informational RFC. This document is the product of the S/MIME Mail Security Working Group. The IESG contact persons are Jeffrey Schiller and Marcus Leech. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9THPZ205981 for ietf-smime-bks; Mon, 29 Oct 2001 09:25:35 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9THPY805976 for <ietf-smime@imc.org>; Mon, 29 Oct 2001 09:25:34 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20757; Mon, 29 Oct 2001 12:25:27 -0500 (EST) Message-Id: <200110291725.MAA20757@ietf.org> To: IETF-Announce: ; Cc: RFC Editor <rfc-editor@isi.edu>, Internet Architecture Board <iab@isi.edu>, ietf-smime@imc.org From: The IESG <iesg-secretary@ietf.org> Subject: Protocol Action: Password-based Encryption for S/MIME to Proposed Standard Date: Mon, 29 Oct 2001 12:25:27 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> The IESG has approved the Internet-Draft 'Password-based Encryption for S/MIME' <draft-ietf-smime-password-06.txt> as a Proposed Standard. This document is the product of the S/MIME Mail Security Working Group. The IESG contact persons are Jeffrey Schiller and Marcus Leech. Technical Summary This protocol describes a password-based content encryption mechanism for CMS. It is an extension to RFC2630. Working Group Summary There was working group concensus on this protocol. One minor comment was received during last call, which resulted in a minor change to the document. Protocol Quality This document was reviewed by Marcus Leech. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9QKtqC01265 for ietf-smime-bks; Fri, 26 Oct 2001 13:55:52 -0700 (PDT) Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9QKto801259 for <ietf-smime@imc.org>; Fri, 26 Oct 2001 13:55:51 -0700 (PDT) Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 26 Oct 2001 20:52:22 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA13587; Fri, 26 Oct 2001 16:55:52 -0400 (EDT) Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id QAA18058; Fri, 26 Oct 2001 16:55:51 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQ8GHG>; Fri, 26 Oct 2001 16:55:41 -0400 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.21]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQ8GH1; Fri, 26 Oct 2001 16:55:35 -0400 From: "Housley, Russ" <rhousley@rsasecurity.com> To: jis@mit.edu, mleech@nortelnetworks.com Cc: ietf-smime@imc.org, scoya@ietf.org Message-Id: <5.0.1.4.2.20011026165115.051fa3d8@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Fri, 26 Oct 2001 16:54:14 -0400 Subject: x400transport and x400wrap Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Jeff & Marcus: The S/MIME WG is finished with two more documents. You may recall a discussion when this work began, and we concluded that they should be published on the Standards Track. The are ready for your review and IETF Last Call. Title : Transporting S/MIME Objects in X.400 Author(s) : P. Hoffman, C. Bonatti Filename : draft-ietf-smime-x400transport-04.txt Date : 19-Oct-01 Title : Securing X.400 Content with S/MIME Author(s) : P. Hoffman, C. Bonatti, A. Eggen Filename : draft-ietf-smime-x400wrap-04.txt Date : 27-Aug-01 Russ Received: by above.proper.com (8.11.6/8.11.3) id f9QIlQs28865 for ietf-smime-bks; Fri, 26 Oct 2001 11:47:26 -0700 (PDT) Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9QIlO828860 for <ietf-smime@imc.org>; Fri, 26 Oct 2001 11:47:25 -0700 (PDT) Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id LAA03349; Fri, 26 Oct 2001 11:39:02 -0700 (PDT) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <VT9AKBBZ>; Fri, 26 Oct 2001 11:47:38 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869844@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Housley, Russ'" <rhousley@rsasecurity.com>, Peter Sylvester <Peter.Sylvester@EdelWeb.fr> Cc: ietf-smime@imc.org Subject: RE: sender-auth and ira Date: Fri, 26 Oct 2001 11:47:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C15E4E.ADCE6810" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C15E4E.ADCE6810 Content-Type: text/plain; charset="iso-8859-1" Oh yeah the BCC to boss strategy... To: Fred BCC: Fred's Boss Fred, I completely understand your situation with the possible loss of the very big important customer account after your unfortunate presentation. Please let me know if there is anything I can do to help you rectify the situation. Mallet. Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Housley, Russ [mailto:rhousley@rsasecurity.com] > Sent: Friday, October 26, 2001 2:21 PM > To: Peter Sylvester > Cc: ietf-smime@imc.org > Subject: Re: sender-auth and ira > > > > Peter: > > > > The whole point of BCC recipients is to keep their > identities from other > > > recipients. If you are going to list them, then they are readily > > > exposed. I do not think that we should introduce this leak. > > > >Isn't this leak is somewhat similar to the possibility of having > >one encryption envelope with all addresses in it? > > Yes. That is why the update to the MSG specification should > address BCC in > the contect of EnvelopedData. > > Russ > ------_=_NextPart_000_01C15E4E.ADCE6810 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C15E4E.ADCE6810-- Received: by above.proper.com (8.11.6/8.11.3) id f9QINk427223 for ietf-smime-bks; Fri, 26 Oct 2001 11:23:46 -0700 (PDT) Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9QINi827219 for <ietf-smime@imc.org>; Fri, 26 Oct 2001 11:23:44 -0700 (PDT) Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 26 Oct 2001 18:20:15 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA03712 for <ietf-smime@imc.org>; Fri, 26 Oct 2001 14:23:46 -0400 (EDT) Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id OAA07327 for <ietf-smime@imc.org>; Fri, 26 Oct 2001 14:23:44 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQ81G2>; Fri, 26 Oct 2001 14:23:33 -0400 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.25]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQ81GC; Fri, 26 Oct 2001 14:23:29 -0400 From: "Housley, Russ" <rhousley@rsasecurity.com> To: Peter Sylvester <Peter.Sylvester@EdelWeb.fr> Cc: ietf-smime@imc.org Message-Id: <5.0.1.4.2.20011026141945.02633758@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Fri, 26 Oct 2001 14:20:44 -0400 Subject: Re: sender-auth and ira In-Reply-To: <200110261539.RAA04013@emeriau.edelweb.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Peter: > > The whole point of BCC recipients is to keep their identities from other > > recipients. If you are going to list them, then they are readily > > exposed. I do not think that we should introduce this leak. > >Isn't this leak is somewhat similar to the possibility of having >one encryption envelope with all addresses in it? Yes. That is why the update to the MSG specification should address BCC in the contect of EnvelopedData. Russ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9QFdrL16995 for ietf-smime-bks; Fri, 26 Oct 2001 08:39:53 -0700 (PDT) Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9QFdp816991 for <ietf-smime@imc.org>; Fri, 26 Oct 2001 08:39:51 -0700 (PDT) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA20851; Fri, 26 Oct 2001 17:39:48 +0200 (MET DST) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 26 Oct 2001 17:39:48 +0200 (MET DST) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA04889; Fri, 26 Oct 2001 17:39:46 +0200 (MET DST) From: Peter Sylvester <Peter.Sylvester@EdelWeb.fr> Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA04013; Fri, 26 Oct 2001 17:39:46 +0200 (MET DST) Date: Fri, 26 Oct 2001 17:39:46 +0200 (MET DST) Message-Id: <200110261539.RAA04013@emeriau.edelweb.fr> To: Peter.Sylvester@EdelWeb.fr, rhousley@rsasecurity.com Subject: Re: sender-auth and ira Cc: ietf-smime@imc.org Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> > The whole point of BCC recipients is to keep their identities from other > recipients. If you are going to list them, then they are readily > exposed. I do not think that we should introduce this leak. Isn't this leak is somewhat similar to the possibility of having one encryption envelope with all addresses in it? Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9QFR6r16110 for ietf-smime-bks; Fri, 26 Oct 2001 08:27:06 -0700 (PDT) Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9QFR4816101 for <ietf-smime@imc.org>; Fri, 26 Oct 2001 08:27:04 -0700 (PDT) Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 26 Oct 2001 15:23:34 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA17194 for <ietf-smime@imc.org>; Fri, 26 Oct 2001 11:27:05 -0400 (EDT) Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id LAA19661 for <ietf-smime@imc.org>; Fri, 26 Oct 2001 11:27:03 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQ8A84>; Fri, 26 Oct 2001 11:26:52 -0400 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.23]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQ8A83; Fri, 26 Oct 2001 11:26:49 -0400 From: "Housley, Russ" <rhousley@rsasecurity.com> To: Peter Sylvester <Peter.Sylvester@EdelWeb.fr> Cc: ietf-smime@imc.org Message-Id: <5.0.1.4.2.20011025182708.02815378@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Thu, 25 Oct 2001 18:32:30 -0400 Subject: Re: sender-auth and ira In-Reply-To: <200110251610.SAA03616@emeriau.edelweb.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Peter: I will respond to your comment in the ira document. I will let Don Davis respond to the other comments. >Section 3.0 sentence 2 and 3 should be moved to the end of the section >where one talks about usage in the context of S/MIME. > >Or, a better separation of the definition of this attribut and its >usage in an S/MIME context should be made. I am pleased to move it to the end of the section. >I am not sure whether I support not including BCCs. This should go >into a security consideration section. The problem is similar of >what happens in standard bcc: processing. It is up to the sending >system to create separate messages which may for example include >one bcc: header for each of the recipients.. similar for S/MIME >envelopes for BCCs, ... The whole point of BCC recipients is to keep their identities from other recipients. If you are going to list them, then they are readily exposed. I do not think that we should introduce this leak. The update to MSG should address BCC in the broader context. >Anyway, a possible and cost intensive solution is to have separate >copies with bccs, signed individually, etc. why should one exclude >this. Yes, there is a cost. Again, BCC should be further addressed in the update to MSG. Russ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9Q3wog11433 for ietf-smime-bks; Thu, 25 Oct 2001 20:58:50 -0700 (PDT) Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9Q3wm811429 for <ietf-smime@imc.org>; Thu, 25 Oct 2001 20:58:48 -0700 (PDT) Received: from cs26.cs.auckland.ac.nz (pgut001@cs26-nfs.cs.auckland.ac.nz [130.216.35.9]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id QAA16777; Fri, 26 Oct 2001 16:58:41 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <100406872106482>; Fri, 26 Oct 2001 16:58:41 (NZDT) From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org, jimsch@exmsft.com, rhousley@rsasecurity.com Subject: RE: sender-auth and ira Reply-To: pgut001@cs.aucKland.ac.nz X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Fri, 26 Oct 2001 16:58:41 (NZDT) Message-ID: <100406872106482@cs26.cs.auckland.ac.nz> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> "Jim Schaad" <jimsch@nwlink.com> writes: >[Snip] > >I think that this is an interesting accademic problem, until I see a real >world need for a solution I think it should be ignored. Unaccustomed as I am to agreeing with Jim :-), I concur with this opinion. Anything of any importance (eg electronic payment instruction, contract, etc) which relies on signatures will include more than enough information in the signed body to resolve any difficulties, and even if there were some pressing demand for this (there isn't), it's not at all clear what a correct solution would be. Speaking of academic exercises, I'm surprised noone's mentioned Serge Vaudenay's PKCS #5 padding attack yet... Peter. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9Q2Vn709983 for ietf-smime-bks; Thu, 25 Oct 2001 19:31:49 -0700 (PDT) Received: from femail1.sdc1.sfba.home.com (femail1.sdc1.sfba.home.com [24.0.95.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9Q2Vm809978 for <ietf-smime@imc.org>; Thu, 25 Oct 2001 19:31:48 -0700 (PDT) Received: from revelation ([65.4.166.11]) by femail1.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20011026023146.YNEV21507.femail1.sdc1.sfba.home.com@revelation>; Thu, 25 Oct 2001 19:31:46 -0700 Reply-To: <jimsch@exmsft.com> From: "Jim Schaad" <jimsch@nwlink.com> To: "'Housley, Russ'" <rhousley@rsasecurity.com>, <ietf-smime@imc.org> Subject: RE: sender-auth and ira Date: Thu, 25 Oct 2001 19:30:57 -0700 Message-ID: <001001c15dc6$3eb82d90$0c00a8c0@soaringhawk.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <5.0.1.4.2.20011025100006.02bfc830@exna07.securitydynamics.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Russ, I was hoping that this issue was going to disappear if I ignored it. I feel that the problem listed, while potentially interesting, is not one that can be solved via this type of mechanism. The problem: I get a message, signed, and I forward it to you signed and then possibly encrypted. You believe that since it was encrypted to you that nobody else could have sent it but the signer. Response: 1) A better answer is to put names in e-mail. 2) Am I suppose to start doing this for all signed mail. 3) How do I convince a large company like Microsoft that this is even an interesting problem for them to "fix" in their mail. 4) This does not fix information leaks in anyway. (A far more interesting problem in my estimation.) Why this does not work: I don't know how to begin to tell Microsoft how to write this code. The simple case is, if my mail box name is not on the To/CC line then pop up a warning message. But this is not an easy thing to say and program in. 1. When I was working at Microsoft, people sent me mail at the address "jimsch@microsoft.com", my mailbox name was "jimsch@exhange.microsoft.com". There is no way to determine that these are or are not the same address. While in this case they were they could just have easily been different addresses. 2. Today, the email address that I give people is "jimsch@exmsft.com", but this is not the mail box address that I use. This address forwards mail to a second address where I down-load my mail from. Now either the message is always going to show up for me, or I have a configuration issue to explain to users (and to write UI for). 3. If I receive e-mail because I am on a mailing list (such as this mailing list), either I get the message for all mail to that list, or I have a configureation issue to explain to users (and to write UI for). This becomes even more fun if you look at nested mailing lists. This mailing list address could be contained on one or more other ietf mailling lists thus I get mail indirectly and infrequently from some other entity mailing list that I do not know that I am on. 4. BCC addressing causes massive problems. Either the message always comes up, I lose the concept of BCC because the address is included, or a separate signature operation must be included for every BCC recipeient. (Does the BCC signature still have the list of all non-BCC recipients?). The process of generating addition signature operations is not acceptable in my estimation, and would likely generate lots of interesting problems with signed receipts. 5. What are the correct processing rules to deal with the following situations: - Nested signatures: Does this element in an outer signature remove the requirement for it to be checked on an inner signature? Does it add or change the behavior in some way? - Parallel signature: What does this mean for two different side-by-side signatures, possible with different recipient lists? If I am on either list I don't need to display this warning? - Nested Messages: What happens if I bodily encapsulate an RFC822 message and forward it to you. Do you check for the encapsulating but not the embedded message? Do you check the embedded message for the from address of the encapsulating message? I think that this is an interesting accademic problem, until I see a real world need for a solution I think it should be ignored. jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Housley, Russ > Sent: Thursday, October 25, 2001 7:05 AM > To: ietf-smime@imc.org > Subject: sender-auth and ira > > > > S/MIME WG: > > Two I-Ds were posted, and I have not seen a single comment on > them. I hope > this message starts a dialogue. > > The two I-Ds are: > draft-ietf-smime-sender-auth-00.txt > draft-ietf-smime-ira-00.txt > > The first one describes a problem, and the second one defines > a solution > for this problem. I would expect the first one to be published an > Informational RFC and the second to be published as a > Standards Track RFC. > > Russ > Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9PMPhq03058 for ietf-smime-bks; Thu, 25 Oct 2001 15:25:43 -0700 (PDT) Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9PMPT803053; Thu, 25 Oct 2001 15:25:29 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: <p0510033ab7fe415ac0dd@[165.227.249.20]> In-Reply-To: <85256AF0.006D932A.00@smtpmail.certicom.com> References: <85256AF0.006D932A.00@smtpmail.certicom.com> Date: Thu, 25 Oct 2001 15:25:24 -0700 To: "Daniel Brown" <dbrown@certicom.com>, "Housley, Russ" <rhousley@rsasecurity.com> From: Paul Hoffman / IMC <phoffman@imc.org> Subject: Re: sender-auth and ira Cc: ietf-smime@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> At 3:57 PM -0400 10/25/01, Daniel Brown wrote: >4. Can the intended-recipients feature be abused? What if Alice >signs "I'll pay you $100." with intended recipients of both Bob and >Carol? Can Alice abuse this to create confusion and deny obligations? This is unavoidable and cannot be part of a standard. We cannot regulate the content of signed and encrypted messages, nor can we regulate the interpretation of that content. We can only regulate the signing and encrypting mechanisms. >6. Does the intended-recipients feature create too much extra >bandwidth by including the names of the intended recipients? If so, >can there be an option where the intended-recipients are omitted >from the CMS entity itself but automatically grabbed from the >TO and CC headers in order computed the signed attributes? Again, we should not be limiting the solution to RFC 2822 messages. CMS is useful for moving lots of kinds of data. --Paul Hoffman, Director --Internet Mail Consortium Received: by above.proper.com (8.11.6/8.11.3) id f9PJwk028948 for ietf-smime-bks; Thu, 25 Oct 2001 12:58:46 -0700 (PDT) Received: from ns.ca.certicom.com (ip5.certicom.com [209.121.99.5] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9PJwi828944 for <ietf-smime@imc.org>; Thu, 25 Oct 2001 12:58:45 -0700 (PDT) Received: from smtpmail.certicom.com (domino2.certicom.com [10.0.1.25]) by ns.ca.certicom.com (Postfix) with SMTP id 8177217DE; Thu, 25 Oct 2001 18:55:11 -0400 (EDT) Received: by smtpmail.certicom.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256AF0.006D94E5 ; Thu, 25 Oct 2001 15:56:55 -0400 X-Lotus-FromDomain: CERTICOM From: "Daniel Brown" <dbrown@certicom.com> To: "Housley, Russ" <rhousley@rsasecurity.com> Cc: ietf-smime@imc.org Message-ID: <85256AF0.006D932A.00@smtpmail.certicom.com> Date: Thu, 25 Oct 2001 15:57:34 -0400 Subject: Re: sender-auth and ira Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Russ and S/MIME WG, I have a few minor comments on ira and sender-auth. 1. AuthenticatedData has built-in resistance to "surreptitious forwarding" when used properly. Proper key management includes static-static DH key agreement, 1-Pass ECMQV or previously distributed symmetric keys. In such cases, the AuthenticatedData will have a "rid" field identifying the recipient's public key or "keyIdentifier" field identifying the recipient's previously distributed symmetric key. This field is enough to ensure that only the recipient identified can authenticate the message. If Bob forwards Alice's AuthenticatedData to Carol, Carol will be notified that the "Authentication Failed". This is a stronger notice than "Valid signature, but you are not an intended recipient". So, I think it would be redundant to include all the TO: and CC: names as intended-recipient authenticated attributes. (But i-r signed attributes are fine.) 2. In the case of BCC, can't "surreptitious forwarding" still be prevented by sending an individual CMS entity to each BCC recipients, distinct from the one common CMS entity sent to all the TO and CC recipients, as would be done normally? Say Carol is on a BCC list. Then she receives an individaul copy of the message, with an individaul CMS object. The CMS can be a SignedData and include Carol as an intended-recipient signed attribute or an AuthenticatedData. Carol will be assured that there is no surreptitious forwarding because she is an i-r or it is a valid auth-data, won't she? 3. Surreptitious forwarding is quite different from non-repudiation. If true repudiation is wanted, then SignedData should be avoided. Even if Alice uses Bob's public key to encrypt the contents before signing it, Alice can't deny her signature on the ciphertext and Bob can reveal the plaintext. With many algorithms, it is possible to verify that ciphertext is public-key encryption of the plaintext using Bob's public key. Bob does not have to reveal his private key, just the plaintext and perhaps a one-time salt-value. To completely avoid non-repudiation, AuthenticatedData should be used instead. 4. Can the intended-recipients feature be abused? What if Alice signs "I'll pay you $100." with intended recipients of both Bob and Carol? Can Alice abuse this to create confusion and deny obligations? 6. Does the intended-recipients feature create too much extra bandwidth by including the names of the intended recipients? If so, can there be an option where the intended-recipients are omitted from the CMS entity itself but automatically grabbed from the TO and CC headers in order computed the signed attributes? Thanks, Dan Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9PGaGv19939 for ietf-smime-bks; Thu, 25 Oct 2001 09:36:16 -0700 (PDT) Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9PGaC819935; Thu, 25 Oct 2001 09:36:12 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: <p0510032bb7fde9fe3a58@[165.227.249.20]> In-Reply-To: <5.0.1.4.2.20011025100006.02bfc830@exna07.securitydynamics.com> References: <5.0.1.4.2.20011025100006.02bfc830@exna07.securitydynamics.com> Date: Thu, 25 Oct 2001 09:36:11 -0700 To: "Housley, Russ" <rhousley@rsasecurity.com>, ietf-smime@imc.org From: Paul Hoffman / IMC <phoffman@imc.org> Subject: Re: sender-auth and ira Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> At 10:04 AM -0400 10/25/01, Housley, Russ wrote: >Two I-Ds were posted, and I have not seen a single comment on them. >I hope this message starts a dialogue. Success. :-) >The two I-Ds are: > draft-ietf-smime-sender-auth-00.txt > draft-ietf-smime-ira-00.txt > >The first one describes a problem, and the second one defines a >solution for this problem. I would expect the first one to be >published an Informational RFC and the second to be published as a >Standards Track RFC. The first draft (sender-auth) defines the problem with a lot of hyperbole. The second draft (ira) defines the problem much better. I would object to the first draft being moved even to Informational status unless: - it was significantly shortened - more emphasis was put on how to avoid the problem without protocol changes ("If Alice puts Bob's name in the first line of the message..." and "If the purchase order has the intended recipient's name in it") - it is stated that the damage that is done by the recipient's carelessness is mostly theoretical and cannot happen when there is intended addressing information in the content The solution in the ira draft is much better than the solution in the sender-auth draft in that it applies to things other than RFC 2822 messages. It seems likely that the sender-auth proposal will become non-interoperable when there are many RFC 2822 headers with recipients in them (such as two To: headers) and with things like header folding. I think the ira draft stands on its own with the problem description and solution. Both drafts would be a lot clearer if they said "sign then encrypt" instead of "sign and encrypt". The word "and" does not mean "then" in most languages, and doesn't necessarily mean it in English. --Paul Hoffman, Director --Internet Mail Consortium Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9PGAwv18791 for ietf-smime-bks; Thu, 25 Oct 2001 09:10:58 -0700 (PDT) Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9PGAt818787 for <ietf-smime@imc.org>; Thu, 25 Oct 2001 09:10:56 -0700 (PDT) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA13563; Thu, 25 Oct 2001 18:10:56 +0200 (MET DST) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 25 Oct 2001 18:10:56 +0200 (MET DST) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA00912; Thu, 25 Oct 2001 18:10:55 +0200 (MET DST) From: Peter Sylvester <Peter.Sylvester@EdelWeb.fr> Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA03616; Thu, 25 Oct 2001 18:10:54 +0200 (MET DST) Date: Thu, 25 Oct 2001 18:10:54 +0200 (MET DST) Message-Id: <200110251610.SAA03616@emeriau.edelweb.fr> To: ietf-smime@imc.org, rhousley@rsasecurity.com Subject: Re: sender-auth and ira Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> here a bit: summary: - having a such an attribute for CMS does not seem a useless idea. - I am not sure about the profiles about how to use this attribute in an S/MIME context. details: > The two I-Ds are: > draft-ietf-smime-sender-auth-00.txt "4.2 Symmetric-Key Semantics" This is only applied to a mode between TWO participants, and not to a mode of one sender and several recipients. If a shared key is used among several then no recipients is sure who has actually created the message. (If a symmetric key is used for each pair, then multiple messages are necessary, see also the comment about bcc later). Or, it isn't clear to me that: " Users tacitly expect public-key file-encryption to offer the same security semantics that a symmetric key offers. " in a context of 1-to-n communication. --- * If the recipient's name doesn't appear in the signed attribute listing the intended recipients, then the recipient's software must inform the recipient that there is a security problem: the author apparently didn't intend the document for this recipient's eyes. I would agree to say : 'the signer did not explicitely indicate that this is intended for the recipient's eyes (and the recipient may have to deduce this information otherwise). > draft-ietf-smime-ira-00.txt Section 3.0 sentence 2 and 3 should be moved to the end of the section where one talks about usage in the context of S/MIME. Or, a better separation of the definition of this attribut and its usage in an S/MIME context should be made. I am not sure whether I support not including BCCs. This should go into a security consideration section. The problem is similar of what happens in standard bcc: processing. It is up to the sending system to create separate messages which may for example include one bcc: header for each of the recipients.. similar for S/MIME envelopes for BCCs, ... Anyway, a possible and cost intensive solution is to have separate copies with bccs, signed individually, etc. why should one exclude this. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9PE55M06736 for ietf-smime-bks; Thu, 25 Oct 2001 07:05:05 -0700 (PDT) Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9PE53806732 for <ietf-smime@imc.org>; Thu, 25 Oct 2001 07:05:03 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 25 Oct 2001 14:01:34 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA15820 for <ietf-smime@imc.org>; Thu, 25 Oct 2001 10:05:04 -0400 (EDT) Received: from exno02.dynas.se (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id KAA08259 for <ietf-smime@imc.org>; Thu, 25 Oct 2001 10:05:02 -0400 (EDT) Received: by exno02.dynas.se with Internet Mail Service (5.5.2653.19) id <4WCBZ0DG>; Thu, 25 Oct 2001 16:04:47 +0200 Received: from HOUSLEY-LAP.rsasecurity.com (housley-lap.securitydynamics.com [10.100.23.218]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQ7QVL; Thu, 25 Oct 2001 10:04:49 -0400 Message-Id: <5.0.1.4.2.20011025100006.02bfc830@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Thu, 25 Oct 2001 10:04:56 -0400 To: ietf-smime@imc.org From: "Housley, Russ" <rhousley@rsasecurity.com> Subject: sender-auth and ira Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> S/MIME WG: Two I-Ds were posted, and I have not seen a single comment on them. I hope this message starts a dialogue. The two I-Ds are: draft-ietf-smime-sender-auth-00.txt draft-ietf-smime-ira-00.txt The first one describes a problem, and the second one defines a solution for this problem. I would expect the first one to be published an Informational RFC and the second to be published as a Standards Track RFC. Russ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9NJrEx24283 for ietf-smime-bks; Tue, 23 Oct 2001 12:53:14 -0700 (PDT) Received: from bonatti-gateway (dial-216-53.capu.net [64.50.216.53]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9NJrB824278 for <ietf-smime@imc.org>; Tue, 23 Oct 2001 12:53:12 -0700 (PDT) Received: from [192.168.1.2] by bonatti-gateway (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Tue, 23 Oct 2001 15:52:58 -0400 From: "Bonatti, Chris" <BonattiC@ieca.com> To: "Musy Michel-P28089" <Michel.Musy@motorola.com> Cc: "Housley, Russ" <rhousley@rsasecurity.com>, <ietf-smime@imc.org> Subject: RE: WG Last Call: x400transport and x400wrap Date: Tue, 23 Oct 2001 15:52:56 -0400 MIME-Version: 1.0 Message-ID: <LOEILJNBHBPKGOPJCMADEEABDHAA.BonattiC@ieca.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0002_01C15BDA.C706BBF0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <01CA656A687ED211926B00805F779140095600F8@az25exm02.geg.mot.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C15BDA.C706BBF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Michel, Not exactly, but close. The "encrypted body" referred to in step 4 is the encryptedContent field of the encryptedContentInfo. However, I think your comment still applies. I would suggest that the parenthetical phrase in step 5 should be replaced with "(the entire EnvelopedData structure)". Please contact me if you have further questions. Chris Bonatti ----------------------------------------------------------- | International Electronic Communication Analysts, Inc. | | Christopher D. Bonatti Tel: 301-208-2349 | | Principal Engineer Fax: 301-208-2379 | ----------------------------------------------------------- -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Musy Michel-P28089 Sent: Monday, October 22, 2001 13:27 To: Housley, Russ; ietf-smime@imc.org Subject: RE: WG Last Call: x400transport and x400wrap Request for Clarification: The following steps decribe how to build a tripple wrapped message with an X.400 content. Is the "encrypted body" only the encryptedContentInfo? This is my understanding. If so, should Step 4 after the text "This is called the "encrypted body"." specify that the enveloped data structure is built? And shouln't Step 5 instead of referencing "(the encrypted body)", should reference the envelope data structure? Attached below Step 4 and Step 5 as they appear in the document. I understand that the "encrypted body" is not the whole envelope data but the whole envelope data structure should be signed. Please clarify if there is something that I misunderstood. Michel email: michel.musy@motorola.com ------------------- From x400wrap-04 ------------------------- Step 4. Encrypt the result of step 3 as a single block. The EnvelopedData encryptedContentInfo contentType MUST be set to id-signedData. This is called the "encrypted body". Step 5. Using the same logic as in step 2 and 3 above, sign the result of step 4 (the encrypted body) as a single block. The SignedData encapContentInfo eContentType MUST be set to id-envelopedData. The outer SignedData structure is encapsulated by a ContentInfo SEQUENCE with a contentType of id-signedData. -----Original Message----- From: Housley, Russ [mailto:rhousley@rsasecurity.com] Sent: Monday, October 22, 2001 7:21 AM To: ietf-smime@imc.org Subject: WG Last Call: x400transport and x400wrap Dear WG Members: We have been in WG Last Call on these two documents for quite some time. The WG Last Call on x400wrap was originally scheduled to end on 14 September, and the WG Last Call for x400transport was originally scheduled to end on 4 October. The authors believe that all comments have been resolved in the current versions. I believe that it is appropriate to progress these two documents at the same time. Title : Transporting S/MIME Objects in X.400 Author(s) : P. Hoffman, C. Bonatti Filename : draft-ietf-smime-x400transport-04.txt Date : 19-Oct-01 Title : Securing X.400 Content with S/MIME Author(s) : P. Hoffman, C. Bonatti, A. Eggen Filename : draft-ietf-smime-x400wrap-04.txt Date : 27-Aug-01 Please review them to confirm that requested changes have been incorporated. Unless traffic on the mail list indicates otherwise, I will send these to the Security Area Directors on Friday, 26 October. So, if you have concerns, please make them known by Thursday. Russ ------=_NextPart_000_0002_01C15BDA.C706BBF0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJsDCCAjww ggGlAhAyUDPPUNFW81yBrWVcT8glMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yMDAxMDcyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQIFAAOBgQBLRGZgaGTkmBvzsHLm lYl83XuzlcAdLtjYGdAtND3GUJoQhoyqPzuoBPw3UpXD2cnbzfKGBsSxG/CCiDBCjhdQHGR6uD6Z SXSX/KwCQ/uWDFYEJQx8fIedJKfY8DIptaTfXaJMxRYyqEL2Raa2Nrngv2U2k8LS12vc3lnWojX4 RTCCAy4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEEBAMCAQYw RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB AgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/ LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDl X4KmsaiSxVhqwY0DPOvDzQWikK5uMIIEOjCCA6OgAwIBAgIQIBArjDV4dZzkRLiqGv4AmTANBgkq hkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEg SW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMDEyMTgw MDAwMDBaFw0wMTEyMzAyMzU5NTlaMIIBFzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUg RnVsbCBTZXJ2aWNlMRwwGgYDVQQDFBNDaHJpc3RvcGhlciBCb25hdHRpMSAwHgYJKoZIhvcNAQkB FhFib25hdHRpY0BpZWNhLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAuOFh05zPSO/F 6uv/0mwKrpW2qJgmdDUfdDzeVC48EDNkTdQ2aPjtgaLPfv8slYzdpb9QbbxJz7aodgxXR9+jooTR 4kEBRVq8vJKwByvmGsk4gP2UAbu3H1Oomc1jSyDHK1op/YcgS74BVuO5iKSiFdUCTMFoItnYsl7q Xz1titUCAwEAAaOBzjCByzAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHAQgwKjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTARBglghkgBhvhCAQEEBAMC B4AwMAYKYIZIAYb4RQEGBwQiFiAwMjM5OTkxMzFmOTk5Njk1ODNhMjMxNjM1MmQwZDAzZjAzBgNV HR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3 DQEBBAUAA4GBAGKIYswPCx9SN+4w+YaUHiUH0NJQr7SBCsPC5wuPjhQZafiu9iT+nKms8REUDtDq Y4jDAIuLoIeW9nZ7iJ5wae9fnFU5g2d1Sh/GMYQiDAztEkYLCMcH3FvPtokgkg3ei+xJhpb4Hb7T tL8OTDTxJPNuIE05ETxnsQyDPEuKnD8mMYIDODCCAzQCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4 MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJz b25hIE5vdCBWYWxpZGF0ZWQCECAQK4w1eHWc5ES4qhr+AJkwCQYFKw4DAhoFAKCCAawwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDExMDIzMTk1MjU0WjAjBgkqhkiG 9w0BCQQxFgQUs7rpe1gzA/56s/wKt4WRbbuqxwMwWAYJKoZIhvcNAQkPMUswSTAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZI hvcNAgUwgfIGCSsGAQQBgjcQBDGB5DCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20v cmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1Zl cmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQIBArjDV4dZzkRLiqGv4AmTANBgkqhkiG9w0BAQEFAASBgIs34xAkJkOmbLQ+30XBmyCP mzN2c3i74tccwKwac9oj1bWYhwGSvDLupsgxXH34Lyblf5pQea3a5qos2NTUIZVgAK5xV9x9UWeg 134t6NMdZ/EkVR56Zo0gFppdUWktcC+1z1Af5S8fl4PRM8OxnQVvQ8gJk1CzUifGROBkW8P+AAAA AAAA ------=_NextPart_000_0002_01C15BDA.C706BBF0-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9MIsNW01181 for ietf-smime-bks; Mon, 22 Oct 2001 11:54:23 -0700 (PDT) Received: from mail.ca (ip6.certicom.com [209.121.99.6] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9MIsL801175 for <ietf-smime@imc.org>; Mon, 22 Oct 2001 11:54:22 -0700 (PDT) Received: from smtpmail.certicom.com (smtpmail [10.0.1.25]) by mail.ca (8.9.3/8.9.3) with SMTP id OAA23650; Mon, 22 Oct 2001 14:46:36 -0400 (EDT) Received: by smtpmail.certicom.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256AED.0067A094 ; Mon, 22 Oct 2001 14:51:53 -0400 X-Lotus-FromDomain: CERTICOM From: "Daniel Brown" <dbrown@certicom.com> To: jimsch@exmsft.com cc: ietf-smime@imc.org Message-ID: <85256AED.00679F74.00@smtpmail.certicom.com> Date: Mon, 22 Oct 2001 14:47:50 -0400 Subject: Re: Questions on AuthenticatedData Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=7v82HNHnA5HtZDOgLk77uD0YVdnvRpGQIDllJTiJzIgFAkyg5HwgZBfF" Content-Disposition: inline Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> --0__=7v82HNHnA5HtZDOgLk77uD0YVdnvRpGQIDllJTiJzIgFAkyg5HwgZBfF Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi Jim, I suggest the following answers to your questions, in the case of HMAC-SHA1 and CMS-3DES-WRAP. 1. We should specify the HMAC-SHA1 key size to be 160 bits (the strength of HMAC-SHA1). 2. When wrapping with 3DES, a 192-bit key is expected, so pad with the HMAC-SHA1 key 32 zero bits (which gives an equivalent 192-bit HMAC-SHA1 key). 3. No. These answers need adjustments for other key wrap and MAC algorithms. Reasoning and further details are given below. Recall that, as Simon, Paul and I noted in our Internet-Draft "Use of ECC Algorithms in S/MIME", if AuthenticatedData uses two or more RecipinientInfo's, then there is a serious problem. Say R1 and R2 are the recipients, the message is M and the MAC key is K. Since R2 receives K, receiver R2 can use it to compute MAC_K(M') for a bogus message M' and then send a bogus AuthenticatedData to R1, using the Wrap_R1(K) already present in the original AuthenticatedData. R1 would think M' originated from the sender even though it originated from R2. Once R2 sees K and Wrap_R1(K), R2 can repeat this attack as often as necessary. Thus, our I-D recommends just one RecipientInfo per AuthenticatedData. Now, a similar attack might apply if a weak MAC key is used. In an extreme case, suppose a sender S sends an AuthenticatedData to a receiver R using a 1-bit MAC key. An adversary A knowing about the 1-bit key can guess the MAC key, confirm its guess, and then launch the above attack. This works no matter how strong the key management and wrap algorithms, because A knows once K and Wrap_R(K), A can send any message to the receiver R in an AuthenticatedData appearing to be from S. If 10-bit MAC key is used, then the attacker has to guess 512 MAC keys on average. If a 40-bit MAC key is used, the sender must guess 2^39 MAC keys on average. Although it is probably impractical, once the guess is made, the attacker can forge as many AuthenticatedData's as desired. Thus the effective strength of AuthenticatedData is limited by the smallest MAC key size used. In fact, in the multi-user setting where 40-bit MAC keys are used, after about 2^20 messages, one expects identical MAC keys to have been used. This might also lead to problems. Thus, I think a minimum HMAC-SHA1 key length should be set. Perhaps 80 bits is enough, but I don't know. Clearly, 160 bits would be safer. The minimum key size should be a MUST or SHOULD for the sender. I realize some implementations may prefer a 128-bit key generator, but this might be a little low. It could be a SHOULD for the receiver, except that one has to be careful about ascertaining the length of the key. Suppose the sender selects a random 160 bit key K, but due to pure chance, the last 8 bits are zero. This could happen with 1 in 256 chance. Should the receiver reject this because it looks like a small key (152 bits)? Probably not. One possible exception to the minimum could be the following. If a key-wrap algorithm Wrap40 only supports 40 bits, then a 40-bit HMAC-SHA1 K40 could be used. The guessing attack can still be launched, but all the forged AuthenticatedData's would contain K40 and Wrap40(K40). It does not seem possible to generate Wrap192(K40), so the attack does not allow forgery of high-strength AuthenticatedData's (assuming the wrap algorithm is secure). My preference would be adapt such a Wrap40 to allow wrapping of longer MAC keys using 40bit encryption. Finally, larger key sizes would not hurt, but do not seem to help, according to the RFC on HMAC-SHA1. Key sizes 193-512 cannot be wrapped with the current 3DES algorithm, but key sizes 513 and larger can be because they are hashed to 160 bits first accoring to the way HMAC-SHA1 is defined. Thanks, Dan "Jim Schaad" <jimsch@nwlink.com> on 10/07/2001 08:56:58 PM Please respond to jimsch@exmsft.com To: ietf-smime@imc.org cc: (bcc: Daniel Brown/Certicom) Subject: Questions on AuthenticatedData I have just started an implemenation for AutenticatedData and have the following questions: 1. Should we specify a suggested size for the randomly generated secret to be used for HMAC-SHA1? (The size for HMAC-3DES is fixed at the size of a 3DES key.) 2. What key wrap algorithm should I use for wrapping the secret for an HMAC-SHA1 secret? I can see myself generating a 512 bit secret for the MAC operation, now I need to wrap it in a 3DES, RC2 or AES key. What is the proper way of doing this? 3. Does the answer for 2 imply that we want the lengths for 1 to be the length of a defined content encrytion algorithm key? Jim --0__=7v82HNHnA5HtZDOgLk77uD0YVdnvRpGQIDllJTiJzIgFAkyg5HwgZBfF Content-type: application/octet-stream; name="att1.eml" Content-Disposition: attachment; filename="att1.eml" Content-transfer-encoding: base64 UmVjZWl2ZWQ6IGZyb20gbWFpbC5jYSAoWzEwLjAuMS42N10pIGJ5IHNtdHBtYWlsLmNlcnRpY29t LmNvbSAoTG90dXMgU01UUCBNVEEgdjQuNi40ICAoODMwLjIgMy0yMy0xOTk5KSkgd2l0aCBTTVRQ IGlkIDg1MjU2QURGLjAwMDg3MzQ0OyBTdW4sIDcgT2N0IDIwMDEgMjE6MzI6MTcgLTA0MDANClJl Y2VpdmVkOiBmcm9tIGFib3ZlLnByb3Blci5jb20gKGFib3ZlLnByb3Blci5jb20gWzIwOC4xODQu NzYuMzldKQ0KCWJ5IG1haWwuY2EgKDguOS4zLzguOS4zKSB3aXRoIEVTTVRQIGlkIFZBQTI5MTQy Ow0KCVN1biwgNyBPY3QgMjAwMSAyMToyNjoxNyAtMDQwMCAoRURUKQ0KUmVjZWl2ZWQ6IGZyb20g bG9jYWxob3N0IChsb2NhbGhvc3QgW1tVTklYOiBsb2NhbGhvc3RdXSkNCglieSBhYm92ZS5wcm9w ZXIuY29tICg4LjExLjYvOC4xMS4zKSBpZCBmOTgwdXVyMjU5MDQNCglmb3IgaWV0Zi1zbWltZS1i a3M7IFN1biwgNyBPY3QgMjAwMSAxNzo1Njo1NiAtMDcwMCAoUERUKQ0KUmVjZWl2ZWQ6IGZyb20g ZmVtYWlsMzEuc2RjMS5zZmJhLmhvbWUuY29tIChmZW1haWwzMS5zZGMxLnNmYmEuaG9tZS5jb20g WzI0LjI1NC42MC4yMV0pDQoJYnkgYWJvdmUucHJvcGVyLmNvbSAoOC4xMS42LzguMTEuMykgd2l0 aCBFU01UUCBpZCBmOTgwdXREMjU5MDANCglmb3IgPGlldGYtc21pbWVAaW1jLm9yZz47IFN1biwg NyBPY3QgMjAwMSAxNzo1Njo1NSAtMDcwMCAoUERUKQ0KUmVjZWl2ZWQ6IGZyb20gcmV2ZWxhdGlv biAoWzY1LjQuMTY2LjExXSkgYnkgZmVtYWlsMzEuc2RjMS5zZmJhLmhvbWUuY29tDQogICAgICAg ICAgKEludGVyTWFpbCB2TS40LjAxLjAzLjIwIDIwMS0yMjktMTIxLTEyMC0yMDAxMDIyMykgd2l0 aCBFU01UUA0KICAgICAgICAgIGlkIDwyMDAxMTAwODAwNTY1My5NTUJRMjg0OTguZmVtYWlsMzEu c2RjMS5zZmJhLmhvbWUuY29tQHJldmVsYXRpb24+DQogICAgICAgICAgZm9yIDxpZXRmLXNtaW1l QGltYy5vcmc+OyBTdW4sIDcgT2N0IDIwMDEgMTc6NTY6NTMgLTA3MDANClJlcGx5LVRvOiA8amlt c2NoQGV4bXNmdC5jb20+DQpGcm9tOiAiSmltIFNjaGFhZCIgPGppbXNjaEBud2xpbmsuY29tPg0K VG86IDxpZXRmLXNtaW1lQGltYy5vcmc+DQpTdWJqZWN0OiBRdWVzdGlvbnMgb24gQXV0aGVudGlj YXRlZERhdGENCkRhdGU6IFN1biwgNyBPY3QgMjAwMSAxNzo1Njo1OCAtMDcwMA0KTWVzc2FnZS1J RDogPDAwNWYwMWMxNGY5NCQyMjM2MWI5MCQwYzAwYThjMEBzb2FyaW5naGF3ay5uZXQ+DQpNSU1F LVZlcnNpb246IDEuMA0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOw0KCWNoYXJzZXQ9IlVTLUFT Q0lJIg0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogN2JpdA0KWC1Qcmlvcml0eTogMyAoTm9y bWFsKQ0KWC1NU01haWwtUHJpb3JpdHk6IE5vcm1hbA0KWC1NYWlsZXI6IE1pY3Jvc29mdCBPdXRs b29rLCBCdWlsZCAxMC4wLjI2MjcNCkltcG9ydGFuY2U6IE5vcm1hbA0KWC1NaW1lT0xFOiBQcm9k dWNlZCBCeSBNaWNyb3NvZnQgTWltZU9MRSBWNi4wMC4yNTI2LjAwMDANClNlbmRlcjogb3duZXIt aWV0Zi1zbWltZUBtYWlsLmltYy5vcmcNClByZWNlZGVuY2U6IGJ1bGsNCkxpc3QtQXJjaGl2ZTog PGh0dHA6Ly93d3cuaW1jLm9yZy9pZXRmLXNtaW1lL21haWwtYXJjaGl2ZS8+DQpMaXN0LUlEOiA8 aWV0Zi1zbWltZS5pbWMub3JnPg0KTGlzdC1VbnN1YnNjcmliZTogPG1haWx0bzppZXRmLXNtaW1l LXJlcXVlc3RAaW1jLm9yZz9ib2R5PXVuc3Vic2NyaWJlPg0KDQoNCkkgaGF2ZSBqdXN0IHN0YXJ0 ZWQgYW4gaW1wbGVtZW5hdGlvbiBmb3IgQXV0ZW50aWNhdGVkRGF0YSBhbmQgaGF2ZSB0aGUNCmZv bGxvd2luZyBxdWVzdGlvbnM6DQoNCjEuICBTaG91bGQgd2Ugc3BlY2lmeSBhIHN1Z2dlc3RlZCBz aXplIGZvciB0aGUgcmFuZG9tbHkgZ2VuZXJhdGVkIHNlY3JldA0KdG8gYmUgdXNlZCBmb3IgSE1B Qy1TSEExPyAgKFRoZSBzaXplIGZvciBITUFDLTNERVMgaXMgZml4ZWQgYXQgdGhlIHNpemUNCm9m IGEgM0RFUyBrZXkuKQ0KDQoyLiAgV2hhdCBrZXkgd3JhcCBhbGdvcml0aG0gc2hvdWxkIEkgdXNl IGZvciB3cmFwcGluZyB0aGUgc2VjcmV0IGZvciBhbg0KSE1BQy1TSEExIHNlY3JldD8gIEkgY2Fu IHNlZSBteXNlbGYgZ2VuZXJhdGluZyBhIDUxMiBiaXQgc2VjcmV0IGZvciB0aGUNCk1BQyBvcGVy YXRpb24sIG5vdyBJIG5lZWQgdG8gd3JhcCBpdCBpbiBhIDNERVMsIFJDMiBvciBBRVMga2V5LiAg V2hhdCBpcw0KdGhlIHByb3BlciB3YXkgb2YgZG9pbmcgdGhpcz8NCg0KDQozLiAgRG9lcyB0aGUg YW5zd2VyIGZvciAyIGltcGx5IHRoYXQgd2Ugd2FudCB0aGUgbGVuZ3RocyBmb3IgMSB0byBiZSB0 aGUNCmxlbmd0aCBvZiBhIGRlZmluZWQgY29udGVudCBlbmNyeXRpb24gYWxnb3JpdGhtIGtleT8N Cg0KSmltDQoNCg== --0__=7v82HNHnA5HtZDOgLk77uD0YVdnvRpGQIDllJTiJzIgFAkyg5HwgZBfF-- Received: by above.proper.com (8.11.6/8.11.3) id f9MHRZm27248 for ietf-smime-bks; Mon, 22 Oct 2001 10:27:35 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9MHRX827239 for <ietf-smime@imc.org>; Mon, 22 Oct 2001 10:27:33 -0700 (PDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id KAA07723 for <ietf-smime@imc.org>; Mon, 22 Oct 2001 10:27:35 -0700 (MST)] Received: [from az33exi01.corp.mot.com (az33exi01.corp.mot.com [199.2.84.10]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id KAA21827 for <ietf-smime@imc.org>; Mon, 22 Oct 2001 10:18:24 -0700 (MST)] Received: by az33exi01.corp.mot.com with Internet Mail Service (5.5.2654.52) id <42YPM1C0>; Mon, 22 Oct 2001 10:27:34 -0700 Message-ID: <01CA656A687ED211926B00805F779140095600F8@az25exm02.geg.mot.com> From: Musy Michel-P28089 <Michel.Musy@motorola.com> To: "Housley, Russ" <rhousley@rsasecurity.com>, ietf-smime@imc.org Subject: RE: WG Last Call: x400transport and x400wrap Date: Mon, 22 Oct 2001 10:27:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Request for Clarification: The following steps decribe how to build a tripple wrapped message with an X.400 content. Is the "encrypted body" only the encryptedContentInfo? This is my understanding. If so, should Step 4 after the text "This is called the "encrypted body"." specify that the enveloped data structure is built? And shouln't Step 5 instead of referencing "(the encrypted body)", should reference the envelope data structure? Attached below Step 4 and Step 5 as they appear in the document. I understand that the "encrypted body" is not the whole envelope data but the whole envelope data structure should be signed. Please clarify if there is something that I misunderstood. Michel email: michel.musy@motorola.com ------------------- From x400wrap-04 ------------------------- Step 4. Encrypt the result of step 3 as a single block. The EnvelopedData encryptedContentInfo contentType MUST be set to id-signedData. This is called the "encrypted body". Step 5. Using the same logic as in step 2 and 3 above, sign the result of step 4 (the encrypted body) as a single block. The SignedData encapContentInfo eContentType MUST be set to id-envelopedData. The outer SignedData structure is encapsulated by a ContentInfo SEQUENCE with a contentType of id-signedData. -----Original Message----- From: Housley, Russ [mailto:rhousley@rsasecurity.com] Sent: Monday, October 22, 2001 7:21 AM To: ietf-smime@imc.org Subject: WG Last Call: x400transport and x400wrap Dear WG Members: We have been in WG Last Call on these two documents for quite some time. The WG Last Call on x400wrap was originally scheduled to end on 14 September, and the WG Last Call for x400transport was originally scheduled to end on 4 October. The authors believe that all comments have been resolved in the current versions. I believe that it is appropriate to progress these two documents at the same time. Title : Transporting S/MIME Objects in X.400 Author(s) : P. Hoffman, C. Bonatti Filename : draft-ietf-smime-x400transport-04.txt Date : 19-Oct-01 Title : Securing X.400 Content with S/MIME Author(s) : P. Hoffman, C. Bonatti, A. Eggen Filename : draft-ietf-smime-x400wrap-04.txt Date : 27-Aug-01 Please review them to confirm that requested changes have been incorporated. Unless traffic on the mail list indicates otherwise, I will send these to the Security Area Directors on Friday, 26 October. So, if you have concerns, please make them known by Thursday. Russ Received: by above.proper.com (8.11.6/8.11.3) id f9MEwOP16242 for ietf-smime-bks; Mon, 22 Oct 2001 07:58:24 -0700 (PDT) Received: from [203.46.112.10] (mail.rsasecurity.com.au [203.46.112.10]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9MEwL816233 for <ietf-smime@imc.org>; Mon, 22 Oct 2001 07:58:21 -0700 (PDT) Received: from [192.168.18.3] by [203.46.112.10] via smtpd (for [208.184.76.43]) with SMTP; 12 Mar 2001 14:00:21 UT Received: from exaus01.local.aus.rsa.com (exaus01.local.aus.rsa.com [10.177.1.15]) by grover.local.aus.rsa.com (8.10.2/8.10.2) with ESMTP id f9MF1qq15751 for <ietf-smime@imc.org>; Tue, 23 Oct 2001 01:01:52 +1000 (EST) Received: by exaus01.local.aus.rsa.com with Internet Mail Service (5.5.2653.19) id <SJYJQXY5>; Tue, 23 Oct 2001 00:56:02 +1000 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.59]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQ6BNX; Mon, 22 Oct 2001 10:57:31 -0400 Message-Id: <5.0.1.4.2.20011022101210.02b4cc50@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Mon, 22 Oct 2001 10:20:49 -0400 To: ietf-smime@imc.org From: "Housley, Russ" <rhousley@rsasecurity.com> Subject: WG Last Call: x400transport and x400wrap Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Dear WG Members: We have been in WG Last Call on these two documents for quite some time. The WG Last Call on x400wrap was originally scheduled to end on 14 September, and the WG Last Call for x400transport was originally scheduled to end on 4 October. The authors believe that all comments have been resolved in the current versions. I believe that it is appropriate to progress these two documents at the same time. Title : Transporting S/MIME Objects in X.400 Author(s) : P. Hoffman, C. Bonatti Filename : draft-ietf-smime-x400transport-04.txt Date : 19-Oct-01 Title : Securing X.400 Content with S/MIME Author(s) : P. Hoffman, C. Bonatti, A. Eggen Filename : draft-ietf-smime-x400wrap-04.txt Date : 27-Aug-01 Please review them to confirm that requested changes have been incorporated. Unless traffic on the mail list indicates otherwise, I will send these to the Security Area Directors on Friday, 26 October. So, if you have concerns, please make them known by Thursday. Russ Received: by above.proper.com (8.11.6/8.11.3) id f9MB4L001182 for ietf-smime-bks; Mon, 22 Oct 2001 04:04:21 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9MB4J801177 for <ietf-smime@imc.org>; Mon, 22 Oct 2001 04:04:20 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10566; Mon, 22 Oct 2001 07:04:17 -0400 (EDT) Message-Id: <200110221104.HAA10566@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-x400transport-04.txt Date: Mon, 22 Oct 2001 07:04:16 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> --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 : Transporting S/MIME Objects in X.400 Author(s) : P. Hoffman, C. Bonatti Filename : draft-ietf-smime-x400transport-04.txt Pages : Date : 19-Oct-01 This document describes protocol options for conveying CMS-protected objects associated with S/MIME version 3 over an X.400 message transfer system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-x400transport-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-x400transport-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-x400transport-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011019141413.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-x400transport-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-x400transport-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011019141413.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by above.proper.com (8.11.6/8.11.3) id f9MB4Bg01175 for ietf-smime-bks; Mon, 22 Oct 2001 04:04:11 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9MB48801169 for <ietf-smime@imc.org>; Mon, 22 Oct 2001 04:04:08 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10542; Mon, 22 Oct 2001 07:04:06 -0400 (EDT) Message-Id: <200110221104.HAA10542@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-password-06.txt Date: Mon, 22 Oct 2001 07:04:05 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> --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 : Password-based Encryption for SMS Author(s) : P. Gutmann Filename : draft-ietf-smime-password-06.txt Pages : Date : 19-Oct-01 The Cryptographic Message Syntax data format doesn't currently contain any provisions for password-based data encryption. This document provides a method of encrypting data using user-supplied passwords and, by extension, any form of variable-length keying material which isn't necessarily an algorithm-specific fixed-format key. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-password-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-password-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-password-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011019141405.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-password-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-password-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011019141405.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9JN03s13060 for ietf-smime-bks; Fri, 19 Oct 2001 16:00:03 -0700 (PDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9JMxvD13044 for <ietf-smime@imc.org>; Fri, 19 Oct 2001 15:59:57 -0700 (PDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id f9JMxtH07737; Fri, 19 Oct 2001 15:59:55 -0700 (PDT) Message-Id: <200110192259.f9JMxtH07737@gamma.isi.edu> To: IETF-Announce: ; Subject: RFC 3183 on Domain Security Services using S/MIME Cc: rfc-ed@ISI.EDU, ietf-smime@imc.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 19 Oct 2001 15:59:55 -0700 From: RFC Editor <rfc-ed@ISI.EDU> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3183 Title: Domain Security Services using S/MIME Author(s): T. Dean, W. Ottaway Status: Experimental Date: October 2001 Mailbox: tbdean@QinetiQ.com, wjottaway@QinetiQ.com Pages: 24 Characters: 57129 SeeAlso/Updates/Obsoletes: None I-D Tag: draft-ietf-smime-domsec-09.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3183.txt This document describes how the S/MIME (Secure/Multipurpose Internet Mail Extensions) protocol can be processed and generated by a number of components of a communication system, such as message transfer agents, guards and gateways to deliver security services. These services are collectively referred to as 'Domain Security Services'. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <011019155915.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3183 --OtherAccess Content-Type: Message/External-body; name="rfc3183.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <011019155915.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- Received: by above.proper.com (8.11.6/8.11.3) id f9JMuoT12982 for ietf-smime-bks; Fri, 19 Oct 2001 15:56:50 -0700 (PDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9JMunD12978 for <ietf-smime@imc.org>; Fri, 19 Oct 2001 15:56:49 -0700 (PDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id f9JMukH07081; Fri, 19 Oct 2001 15:56:46 -0700 (PDT) Message-Id: <200110192256.f9JMukH07081@gamma.isi.edu> To: IETF-Announce: ; Subject: RFC 3185 on Reuse of CMS Content Encryption Keys Cc: rfc-ed@ISI.EDU, ietf-smime@imc.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 19 Oct 2001 15:56:46 -0700 From: RFC Editor <rfc-ed@ISI.EDU> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3185 Title: Reuse of CMS Content Encryption Keys Author(s): S. Farrell, S. Turner Status: Standards Track Date: October 2001 Mailbox: stephen.farrell@baltimore.ie, turners@ieca.com Pages: 10 Characters: 20404 SeeAlso/Updates/Obsoletes: None I-D Tag: draft-ietf-smime-rcek-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3185.txt This document describes a way to include a key identifier in a CMS (Cryptographic Message Syntax) enveloped data structure, so that the content encryption key can be re-used for further enveloped data packets. This document is a product of the S/MIME Mail Security Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <011019155559.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3185 --OtherAccess Content-Type: Message/External-body; name="rfc3185.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <011019155559.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9JMpXB12876 for ietf-smime-bks; Fri, 19 Oct 2001 15:51:33 -0700 (PDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9JMpVD12872 for <ietf-smime@imc.org>; Fri, 19 Oct 2001 15:51:31 -0700 (PDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id f9JMpNH05763; Fri, 19 Oct 2001 15:51:23 -0700 (PDT) Message-Id: <200110192251.f9JMpNH05763@gamma.isi.edu> To: IETF-Announce: ; Subject: RFC 3126 on Electronic Signature Formats Cc: rfc-ed@ISI.EDU, ietf-smime@imc.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 19 Oct 2001 15:51:23 -0700 From: RFC Editor <rfc-ed@ISI.EDU> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3126 Title: Electronic Signature Formats for long term electronic signatures Author(s): D. Pinkas, J. Ross, N. Pope Status: Informational Date: September 2001 Mailbox: harri.rasilainen@etsi.fr, Denis.Pinkas @bull.net, ross@secstan.com, pope@secstan.com Pages: 84 Characters: 175886 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-smime-esformats-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3126.txt This document defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (i.e., repudiates the validity of the signature). The format can be considered as an extension to RFC 2630 and RFC 2634, where, when appropriate additional signed and unsigned attributes have been defined. The contents of this Informational RFC is technically equivalent to ETSI TS 101 733 V.1.2.2. The ETSI TS is under the ETSI Copyright (C). Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org This document is a product of the S/MIME Mail Security Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <011019155039.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3126 --OtherAccess Content-Type: Message/External-body; name="rfc3126.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <011019155039.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9JMoXG12824 for ietf-smime-bks; Fri, 19 Oct 2001 15:50:33 -0700 (PDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9JMoWD12820 for <ietf-smime@imc.org>; Fri, 19 Oct 2001 15:50:32 -0700 (PDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id f9JMoNH05739; Fri, 19 Oct 2001 15:50:23 -0700 (PDT) Message-Id: <200110192250.f9JMoNH05739@gamma.isi.edu> To: IETF-Announce: ; Subject: RFC 3125 on Electronic Signature Policies Cc: rfc-ed@ISI.EDU, ietf-smime@imc.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 19 Oct 2001 15:50:23 -0700 From: RFC Editor <rfc-ed@ISI.EDU> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3125 Title: Electronic Signature Policies Author(s): J. Ross, D. Pinkas, N. Pope Status: Experimental Date: September 2001 Mailbox: harri.rasilainen@etsi.fr, ross@secstan.com, pope@secstan.com Pages: 43 Characters: 95505 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-smime-espolicies-00.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3125.txt This document defines signature policies for electronic signatures. A signature policy is a set of rules for the creation and validation of an electronic signature, under which the validity of signature can be determined. A given legal/contractual context may recognize a particular signature policy as meeting its requirements. A signature policy has a globally unique reference, which is bound to an electronic signature by the signer as part of the signature calculation. The signature policy needs to be available in human readable form so that it can be assessed to meet the requirements of the legal and contractual context in which it is being applied. To allow for the automatic processing of an electronic signature another part of the signature policy specifies the electronic rules for the creation and validation of the electronic signature in a computer processable form. In the current document the format of the signature policy is defined using ASN.1. The contents of this document is based on the signature policy defined in ETSI TS 101 733 V.1.2.2 (2000-12) Copyright (C). Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org. This document is a product of the S/MIME Mail Security Working Group of the IETF. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <011019154933.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3125 --OtherAccess Content-Type: Message/External-body; name="rfc3125.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <011019154933.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9HImYR17817 for ietf-smime-bks; Wed, 17 Oct 2001 11:48:34 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9HImWD17812 for <ietf-smime@imc.org>; Wed, 17 Oct 2001 11:48:32 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03577; Wed, 17 Oct 2001 14:48:21 -0400 (EDT) Message-Id: <200110171848.OAA03577@ietf.org> To: IETF-Announce: ; Subject: RFC 3183 on Domain Security Services using S/MIME Cc: rfc-ed@ISI.EDU, ietf-smime@imc.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: RFC Editor <rfc-ed@ISI.EDU> Date: Wed, 17 Oct 2001 14:48:21 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> A new Request for Comments is now available in online RFC libraries. RFC 3183 Title: Domain Security Services using S/MIME Author(s): T. Dean, W. Ottaway Status: Experimental Date: October 2001 Mailbox: tbdean@QinetiQ.com, wjottaway@QinetiQ.com Pages: 24 Characters: 57129 SeeAlso/Updates/Obsoletes: None I-D Tag: draft-ietf-smime-domsec-09.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3183.txt This document describes how the S/MIME (Secure/Multipurpose Internet Mail Extensions) protocol can be processed and generated by a number of components of a communication system, such as message transfer agents, guards and gateways to deliver security services. These services are collectively referred to as 'Domain Security Services'. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ----- End Included Message ----- ---------- X-Sun-Data-Type: Multipart X-Sun-Content-Length: 490 X-Sun-Charset: us-ascii X-Sun-Content-Lines: 22 --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <011012162515.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3183 --OtherAccess Content-Type: Message/External-body; name="rfc3183.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <011012162515.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9HIlv417799 for ietf-smime-bks; Wed, 17 Oct 2001 11:47:57 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9HIltD17794 for <ietf-smime@imc.org>; Wed, 17 Oct 2001 11:47:55 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03540; Wed, 17 Oct 2001 14:47:53 -0400 (EDT) Message-Id: <200110171847.OAA03540@ietf.org> To: IETF-Announce: ; Subject: RFC 3126 on Electronic Signature Formats Cc: rfc-ed@ISI.EDU, ietf-smime@imc.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: RFC Editor <rfc-ed@ISI.EDU> Date: Wed, 17 Oct 2001 14:47:53 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> A new Request for Comments is now available in online RFC libraries. RFC 3126 Title: Electronic Signature Formats for long term electronic signatures Author(s): D. Pinkas, J. Ross, N. Pope Status: Informational Date: September 2001 Mailbox: harri.rasilainen@etsi.fr, Denis.Pinkas @bull.net, ross@secstan.com, pope@secstan.com Pages: 84 Characters: 175886 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-smime-esformats-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3126.txt This document defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (i.e., repudiates the validity of the signature). The format can be considered as an extension to RFC 2630 and RFC 2634, where, when appropriate additional signed and unsigned attributes have been defined. The contents of this Informational RFC is technically equivalent to ETSI TS 101 733 V.1.2.2. The ETSI TS is under the ETSI Copyright (C). Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org This document is a product of the S/MIME Mail Security Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ----- End Included Message ----- ---------- X-Sun-Data-Type: Multipart X-Sun-Content-Length: 490 X-Sun-Charset: us-ascii X-Sun-Content-Lines: 22 --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <010924102422.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3126 --OtherAccess Content-Type: Message/External-body; name="rfc3126.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <010924102422.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9HIlrs17792 for ietf-smime-bks; Wed, 17 Oct 2001 11:47:53 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9HIlpD17788 for <ietf-smime@imc.org>; Wed, 17 Oct 2001 11:47:51 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03535; Wed, 17 Oct 2001 14:47:48 -0400 (EDT) Message-Id: <200110171847.OAA03535@ietf.org> To: IETF-Announce: ; Subject: RFC 3125 on Electronic Signature Policies Cc: rfc-ed@ISI.EDU, ietf-smime@imc.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: RFC Editor <rfc-ed@ISI.EDU> Date: Wed, 17 Oct 2001 14:47:48 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> A new Request for Comments is now available in online RFC libraries. RFC 3125 Title: Electronic Signature Policies Author(s): J. Ross, D. Pinkas, N. Pope Status: Experimental Date: September 2001 Mailbox: harri.rasilainen@etsi.fr, ross@secstan.com, pope@secstan.com Pages: 43 Characters: 95505 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-smime-espolicies-00.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3125.txt This document defines signature policies for electronic signatures. A signature policy is a set of rules for the creation and validation of an electronic signature, under which the validity of signature can be determined. A given legal/contractual context may recognize a particular signature policy as meeting its requirements. A signature policy has a globally unique reference, which is bound to an electronic signature by the signer as part of the signature calculation. The signature policy needs to be available in human readable form so that it can be assessed to meet the requirements of the legal and contractual context in which it is being applied. To allow for the automatic processing of an electronic signature another part of the signature policy specifies the electronic rules for the creation and validation of the electronic signature in a computer processable form. In the current document the format of the signature policy is defined using ASN.1. The contents of this document is based on the signature policy defined in ETSI TS 101 733 V.1.2.2 (2000-12) Copyright (C). Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org. This document is a product of the S/MIME Mail Security Working Group of the IETF. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ----- End Included Message ----- ---------- X-Sun-Data-Type: Multipart X-Sun-Content-Length: 490 X-Sun-Charset: us-ascii X-Sun-Content-Lines: 22 --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <010924102113.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3125 --OtherAccess Content-Type: Message/External-body; name="rfc3125.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <010924102113.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9GKlQL09382 for ietf-smime-bks; Tue, 16 Oct 2001 13:47:26 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9GKlID09377 for <ietf-smime@imc.org>; Tue, 16 Oct 2001 13:47:20 -0700 (PDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id f9GKkMO17085; Tue, 16 Oct 2001 13:46:22 -0700 (PDT) Message-Id: <200110162046.f9GKkMO17085@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 3185 on Reuse of CMS Content Encryption Keys Cc: rfc-ed@ISI.EDU, ietf-smime@imc.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 16 Oct 2001 13:46:22 -0700 From: RFC Editor <rfc-ed@ISI.EDU> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3185 Title: Reuse of CMS Content Encryption Keys Author(s): S. Farrell, S. Turner Status: Standards Track Date: October 2001 Mailbox: stephen.farrell@baltimore.ie, turners@ieca.com Pages: 10 Characters: 20404 SeeAlso/Updates/Obsoletes: None I-D Tag: draft-ietf-smime-rcek-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3185.txt This document describes a way to include a key identifier in a CMS (Cryptographic Message Syntax) enveloped data structure, so that the content encryption key can be re-used for further enveloped data packets. This document is a product of the S/MIME Mail Security Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <011016134423.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3185 --OtherAccess Content-Type: Message/External-body; name="rfc3185.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <011016134423.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- Received: by above.proper.com (8.11.6/8.11.3) id f9FJiB314881 for ietf-smime-bks; Mon, 15 Oct 2001 12:44:11 -0700 (PDT) Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9FJiAD14877 for <ietf-smime@imc.org>; Mon, 15 Oct 2001 12:44:11 -0700 (PDT) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <43TPYBAY>; Mon, 15 Oct 2001 15:50:29 -0400 Message-ID: <0B95FB5619B3D411817E006008A59259B51CE2@wfhqex06.gfgsi.com> From: "Pawling, John" <John.Pawling@GetronicsGov.com> To: ietf-smime@imc.org Subject: RE: WG Last Call: cmsalg Date: Mon, 15 Oct 2001 15:50:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Magnus, I still agree with Jim Schaad's original point that the S/MIME specs should import the certificate, CRL and attribute certificate ASN.1 syntaxes (and components thereof) from the ASN.1 modules in the PKIX specs since the PKIX working group is the authoritative source for the IETF regarding the specification of those objects. It would be great news if all of the ITU-T Recommendations were freely available. However, the ITU-T web page <http://www.itu.int/ITU-T/publications/index.html> states: "ITU-T Recommendations in Force These are available for purchase and published in different forms - individual paper fascicles, individual electronic files, entire collection on CD-ROM, through yearly on-line subscription to all Recommendations in force." Also, in a message sent to the PKIX mail list in May 2001, Hoyt Kesterson stated: "ITU is allowing any three recommendations to be downloaded at no cost from their server." I have never seen a statement that all of the ITU-T Recommendations were freely available. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== -----Original Message----- From: Magnus Nystrom [mailto:magnus@rsasecurity.com] Sent: Friday, October 12, 2001 5:23 AM To: ietf-smime@imc.org Subject: RE: WG Last Call: cmsalg Actually, it turns out that they indeed are freely available: http://www.itu.int/ITU-T/asn1/database/itu-t/x/index.html Many Thanks to Hoyt Kesterson for informing me about this. Hoyt mentioned to me that the database perhaps is not complete yet; a quick look however indicates that all needed v3 modules are in place. So, perhaps S/MIME could reference these modules after all... BR, -- Magnus Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9CNQaQ20206 for ietf-smime-bks; Fri, 12 Oct 2001 16:26:36 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9CNQZD20202 for <ietf-smime@imc.org>; Fri, 12 Oct 2001 16:26:35 -0700 (PDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id f9CNQXO12612; Fri, 12 Oct 2001 16:26:33 -0700 (PDT) Message-Id: <200110122326.f9CNQXO12612@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 3183 on Domain Security Services using S/MIME Cc: rfc-ed@ISI.EDU, ietf-smime@imc.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 12 Oct 2001 16:26:33 -0700 From: RFC Editor <rfc-ed@ISI.EDU> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3183 Title: Domain Security Services using S/MIME Author(s): T. Dean, W. Ottaway Status: Experimental Date: October 2001 Mailbox: tbdean@QinetiQ.com, wjottaway@QinetiQ.com Pages: 24 Characters: 57129 SeeAlso/Updates/Obsoletes: None I-D Tag: draft-ietf-smime-domsec-09.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3183.txt This document describes how the S/MIME (Secure/Multipurpose Internet Mail Extensions) protocol can be processed and generated by a number of components of a communication system, such as message transfer agents, guards and gateways to deliver security services. These services are collectively referred to as 'Domain Security Services'. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <011012162515.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3183 --OtherAccess Content-Type: Message/External-body; name="rfc3183.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <011012162515.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9CGu6H10583 for ietf-smime-bks; Fri, 12 Oct 2001 09:56:06 -0700 (PDT) Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9CGu4D10579 for <ietf-smime@imc.org>; Fri, 12 Oct 2001 09:56:04 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for [208.184.76.43]) with SMTP; 12 Oct 2001 16:52:49 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA15224; Fri, 12 Oct 2001 12:56:05 -0400 (EDT) Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id MAA21307; Fri, 12 Oct 2001 12:56:04 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQXD20>; Fri, 12 Oct 2001 12:55:59 -0400 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.78]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQXD28; Fri, 12 Oct 2001 12:55:56 -0400 From: "Housley, Russ" <rhousley@rsasecurity.com> To: w.ottaway@eris.QinetiQ.com, blaker@tumbleweed.com Cc: ietf-smime@imc.org Message-Id: <5.0.1.4.2.20011012124757.00b0b5a0@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Fri, 12 Oct 2001 12:51:33 -0400 Subject: RE: DOMSEC and S/MIME Gateway Protocol comparison In-Reply-To: <NABBJNEAKNOGJBHIOCBHIEILEBAA.w.ottaway@eris.QinetiQ.com> References: <01FF24001403D011AD7B00A024BC53C5BD16E7@cane.deming.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Bill & Blake: I would prefer that a encrypt-only-DOMSEC implementation preserve any signature that is already in place, but not add an empty signature wrapper. I look forward to the harmonized draft. Blake, when the draft is ready, please post it as draft-ietf-smime-enc-only-domsec-00.txt. Russ At 03:36 PM 10/12/2001 +0100, William Ottaway wrote: >Hi Blake, > >The DOMSEC draft does not require triple-wrapping it only states that it is >supported. A message that only follows the DOMSEC encryption rules, i.e. no >added signature, would be DOMSEC compliant. > >The empty signature is only a requirement when you are applying a DOMSEC >signature to a message that does not already have a signature. This rule was >added for backward compatibility. Since you are only encrypting this is not >an issue for you. If you were to support signatures then your system may >enforce that a signature is always present before a DOMSEC signature is >applied or you could have a profile of DOMSEC that ignores the empty >signature rule, assuming backwards compatibility is not an issue. > >Bill. > >____________________________________________________ > William Ottaway BSc Hons CEng MBCS, > Woodward B009, > QinetiQ Tel: +44 (0) 1684 894079 > Malvern Technology Centre, Fax: +44 (0) 1684 896660 > St. Andrews Road, email: w.ottaway@eris.QinetiQ.com > Malvern, > Worcs, > WR14 3PS > > All opinions are my own. > > > > -----Original Message----- > > From: owner-ietf-smime@mail.imc.org > > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Blake Ramsdell > > Sent: 04 October 2001 21:00 > > To: 'William Ottaway'; ietf-smime@imc.org > > Subject: RE: DOMSEC and S/MIME Gateway Protocol comparison > > > > > > > > Bill, thanks very much for doing this summary. > > > > One thing that we were initially concerned about was that there was a > > requirement for triple-wrapping and/or an empty signature layer > > (SignedData > > with no SignerInfos). If this requirement is gone, then I believe we can > > simply make our document an "encrypting-only" profile for DOMSEC. > > > > I propose that our current document continue to live, but with > > the following > > changes: > > > > 1. Refer to DOMSEC in the relevant places in our draft > > > > 2. Remove the language about the email address in the > > certificate, and refer > > to DOMSEC for this > > > > 3. Clarify that the additions that we have specified for handling > > subdomains, etc. are in addition to DOMSEC (and thus the meat of this > > profile) > > > > The only impact for any existing implementations of our > > specification would > > therefore be the recognition of the DOMSEC-specified email address > > (domain-confidentiality-authority) as opposed to the smg_encryptor email > > address that we originally specified in our draft. > > > > Blake > > > > -----Original Message----- > > From: William Ottaway [mailto:w.ottaway@eris.dera.gov.uk] > > Sent: Friday, September 21, 2001 6:42 AM > > To: ietf-smime@imc.org > > Cc: Blake Ramsdell > > Subject: DOMSEC and S/MIME Gateway Protocol comparison > > > > > > > > > > At the S/MIME WG meeting in London I was tasked to provide a comparison > > between DOMSEC and the S/MIME Gateway Protocol > > (draft-ramsdell-enc-smime-gateway-00.txt) in order to start a > > discussion on > > whether the gateway draft should be progressed and if so how > > would it relate > > to DOMSEC. > > > > > > DOMSEC Summary: - > > > > 1) Encryption/Decryption and signing. > > > > 2) Defines naming conventions. > > > > 3) Defines signature types. > > > > 4) Defines membership of a domain. > > > > 5) Defines rules for domain signature generation and verification. > > > > 6) States how domain encryption/decryption is achieved. > > > > 7) Defines domain signature application rules when sending to mail list > > agents. > > > > > > Gateway Summary: - > > > > 1) Encryption/Decryption only. > > > > 2) Uses same notation of domain "membership" as DOMSEC. > > > > 3) Introduces its own naming convention for the encrypting entities domain > > certificate, smg_encryptor@domain. DOMSEC defines > > domain-confidentiality-authority@domain. > > > > 4) Introduces a mechanism for identifying multiple domains handled by the > > gateway. They can be listed in a single certificate or in multiple > > certificates. > > > > 5) Introduces a rule for deciding which recipient domain > > certificate must be > > used. > > > > 6) Introduces a rule on how the gateway recognises that a message requires > > encryption (encrypt if have a certificate for the recipients domain). > > > > 7) Introduces a rule on when the gateway should decrypt a message > > (when the > > gateways public key has been used to encrypt) > > > > > > My view: - > > > > DOMSEC defines mechanisms for domain signing and encrypting with out > > specifying mechanisms or rules that are deemed local to the > > installation. It > > is hoped that domain signing and encryption implementations will be > > compliant with DOMSEC. It is expected that individual installations will > > provide extra local mechanisms and rules in support of DOMSEC, for example > > how to decide on which certificate to use, how to decide on whether > > encryption is required, how certificates are retrieved, whether a domain > > signature is stripped off before forwarding to the local > > recipient, whether > > encryption between the domain boundary and the local recipient is > > required, > > etc. > > > > The Gateway draft defines mechanisms that are already defined in DOMSEC, > > such as encryption and naming notation. It also defines > > mechanisms that may > > differ between implementations, such as domains that are handled by the > > gateway may be listed in a single or multiple certificate and > > rules on which > > recipient certificate to use when encrypting. > > > > I propose that the Gateway draft should be a profile of DOMSEC. Therefore, > > it should support encryption/decryption as specified in DOMSEC and the > > DOMSEC naming convention. The Gateway draft would contain those features > > local to this implementation such as points 4 - 7 in the gateway summary. > > > > Bill > > ____________________________________________________ > > William Ottaway BSc Hons CEng MBCS, > > Woodward B009, > > QinetiQ Tel: +44 (0) 1684 894079 > > Malvern Technology Centre, Fax: +44 (0) 1684 896660 > > St. Andrews Road, email: wjottaway@QinetiQ.com > > Malvern, > > Worcs, > > WR14 3PS > > > > All opinions are my own. > > > > > > Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9CEZ5902327 for ietf-smime-bks; Fri, 12 Oct 2001 07:35:05 -0700 (PDT) Received: from mail.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9CEZ2D02323 for <ietf-smime@imc.org>; Fri, 12 Oct 2001 07:35:03 -0700 (PDT) Received: (qmail 9738 invoked from network); 12 Oct 2001 14:34:42 -0000 Received: from mailhost.eris.dera.gov.uk (qmailr@128.98.2.2) by ens0.eris.dera.gov.uk with SMTP; 12 Oct 2001 14:34:42 -0000 Received: (qmail 5877 invoked by uid 2853); 12 Oct 2001 15:38:49 -0000 Received: from wottaway.eris.dera.gov.uk (HELO WOTTAWAY) (128.98.10.192) by mailhost.eris.dera.gov.uk with SMTP; 12 Oct 2001 15:38:46 -0000 From: "William Ottaway" <w.ottaway@eris.QinetiQ.com> To: "Blake Ramsdell" <blaker@tumbleweed.com> Cc: <ietf-smime@imc.org> Subject: RE: DOMSEC and S/MIME Gateway Protocol comparison Date: Fri, 12 Oct 2001 15:36:28 +0100 Message-ID: <NABBJNEAKNOGJBHIOCBHIEILEBAA.w.ottaway@eris.QinetiQ.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <01FF24001403D011AD7B00A024BC53C5BD16E7@cane.deming.com> X-Virus-Scanned: by internal AMaViS perl-11 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Hi Blake, The DOMSEC draft does not require triple-wrapping it only states that it is supported. A message that only follows the DOMSEC encryption rules, i.e. no added signature, would be DOMSEC compliant. The empty signature is only a requirement when you are applying a DOMSEC signature to a message that does not already have a signature. This rule was added for backward compatibility. Since you are only encrypting this is not an issue for you. If you were to support signatures then your system may enforce that a signature is always present before a DOMSEC signature is applied or you could have a profile of DOMSEC that ignores the empty signature rule, assuming backwards compatibility is not an issue. Bill. ____________________________________________________ William Ottaway BSc Hons CEng MBCS, Woodward B009, QinetiQ Tel: +44 (0) 1684 894079 Malvern Technology Centre, Fax: +44 (0) 1684 896660 St. Andrews Road, email: w.ottaway@eris.QinetiQ.com Malvern, Worcs, WR14 3PS All opinions are my own. > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Blake Ramsdell > Sent: 04 October 2001 21:00 > To: 'William Ottaway'; ietf-smime@imc.org > Subject: RE: DOMSEC and S/MIME Gateway Protocol comparison > > > > Bill, thanks very much for doing this summary. > > One thing that we were initially concerned about was that there was a > requirement for triple-wrapping and/or an empty signature layer > (SignedData > with no SignerInfos). If this requirement is gone, then I believe we can > simply make our document an "encrypting-only" profile for DOMSEC. > > I propose that our current document continue to live, but with > the following > changes: > > 1. Refer to DOMSEC in the relevant places in our draft > > 2. Remove the language about the email address in the > certificate, and refer > to DOMSEC for this > > 3. Clarify that the additions that we have specified for handling > subdomains, etc. are in addition to DOMSEC (and thus the meat of this > profile) > > The only impact for any existing implementations of our > specification would > therefore be the recognition of the DOMSEC-specified email address > (domain-confidentiality-authority) as opposed to the smg_encryptor email > address that we originally specified in our draft. > > Blake > > -----Original Message----- > From: William Ottaway [mailto:w.ottaway@eris.dera.gov.uk] > Sent: Friday, September 21, 2001 6:42 AM > To: ietf-smime@imc.org > Cc: Blake Ramsdell > Subject: DOMSEC and S/MIME Gateway Protocol comparison > > > > > At the S/MIME WG meeting in London I was tasked to provide a comparison > between DOMSEC and the S/MIME Gateway Protocol > (draft-ramsdell-enc-smime-gateway-00.txt) in order to start a > discussion on > whether the gateway draft should be progressed and if so how > would it relate > to DOMSEC. > > > DOMSEC Summary: - > > 1) Encryption/Decryption and signing. > > 2) Defines naming conventions. > > 3) Defines signature types. > > 4) Defines membership of a domain. > > 5) Defines rules for domain signature generation and verification. > > 6) States how domain encryption/decryption is achieved. > > 7) Defines domain signature application rules when sending to mail list > agents. > > > Gateway Summary: - > > 1) Encryption/Decryption only. > > 2) Uses same notation of domain "membership" as DOMSEC. > > 3) Introduces its own naming convention for the encrypting entities domain > certificate, smg_encryptor@domain. DOMSEC defines > domain-confidentiality-authority@domain. > > 4) Introduces a mechanism for identifying multiple domains handled by the > gateway. They can be listed in a single certificate or in multiple > certificates. > > 5) Introduces a rule for deciding which recipient domain > certificate must be > used. > > 6) Introduces a rule on how the gateway recognises that a message requires > encryption (encrypt if have a certificate for the recipients domain). > > 7) Introduces a rule on when the gateway should decrypt a message > (when the > gateways public key has been used to encrypt) > > > My view: - > > DOMSEC defines mechanisms for domain signing and encrypting with out > specifying mechanisms or rules that are deemed local to the > installation. It > is hoped that domain signing and encryption implementations will be > compliant with DOMSEC. It is expected that individual installations will > provide extra local mechanisms and rules in support of DOMSEC, for example > how to decide on which certificate to use, how to decide on whether > encryption is required, how certificates are retrieved, whether a domain > signature is stripped off before forwarding to the local > recipient, whether > encryption between the domain boundary and the local recipient is > required, > etc. > > The Gateway draft defines mechanisms that are already defined in DOMSEC, > such as encryption and naming notation. It also defines > mechanisms that may > differ between implementations, such as domains that are handled by the > gateway may be listed in a single or multiple certificate and > rules on which > recipient certificate to use when encrypting. > > I propose that the Gateway draft should be a profile of DOMSEC. Therefore, > it should support encryption/decryption as specified in DOMSEC and the > DOMSEC naming convention. The Gateway draft would contain those features > local to this implementation such as points 4 - 7 in the gateway summary. > > Bill > ____________________________________________________ > William Ottaway BSc Hons CEng MBCS, > Woodward B009, > QinetiQ Tel: +44 (0) 1684 894079 > Malvern Technology Centre, Fax: +44 (0) 1684 896660 > St. Andrews Road, email: wjottaway@QinetiQ.com > Malvern, > Worcs, > WR14 3PS > > All opinions are my own. > > > Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9C9LlL24362 for ietf-smime-bks; Fri, 12 Oct 2001 02:21:47 -0700 (PDT) Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9C9LkD24358 for <ietf-smime@imc.org>; Fri, 12 Oct 2001 02:21:46 -0700 (PDT) Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for [208.184.76.43]) with SMTP; 12 Oct 2001 09:18:30 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id FAA07521 for <ietf-smime@imc.org>; Fri, 12 Oct 2001 05:21:46 -0400 (EDT) Received: from spirit.dynas.se (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with SMTP id FAA10717 for <ietf-smime@imc.org>; Fri, 12 Oct 2001 05:21:44 -0400 (EDT) Received: (qmail 29903 invoked from network); 12 Oct 2001 09:21:44 -0000 Received: from dsf.dynas.se (192.168.102.2) by spirit.dynas.se with SMTP; 12 Oct 2001 09:21:44 -0000 Received: (qmail 6170 invoked from network); 12 Oct 2001 09:21:43 -0000 Received: from karoni.sto.dynas.se (HELO mnystrom-lap) (192.168.102.2) by karoni.sto.dynas.se with SMTP; 12 Oct 2001 09:21:43 -0000 Date: Fri, 12 Oct 2001 11:22:48 +0200 (W. Europe Daylight Time) From: Magnus Nystrom <magnus@rsasecurity.com> To: <ietf-smime@imc.org> Subject: RE: WG Last Call: cmsalg In-Reply-To: <Pine.WNT.4.31.0110111428160.1168-100000@mnystrom-lap> Message-ID: <Pine.WNT.4.31.0110120853410.1728-100000@mnystrom-lap> X-X-Sender: magnus@dsf.dynas.se MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Actually, it turns out that they indeed are freely available: http://www.itu.int/ITU-T/asn1/database/itu-t/x/index.html Many Thanks to Hoyt Kesterson for informing me about this. Hoyt mentioned to me that the database perhaps is not complete yet; a quick look however indicates that all needed v3 modules are in place. So, perhaps S/MIME could reference these modules after all... BR, -- Magnus On Thu, 11 Oct 2001, Magnus Nystrom wrote: > ...though of course X.509 ASN.1 modules are not freely available > (AFAIK), > > Sorry for any confusion, > -- Magnus > > On Thu, 11 Oct 2001, Magnus Nystrom wrote: > > > John Pawling wrote: > > > > [...] > > > I agree with Jim Schaad that the S/MIME specs should reference > > > the ASN.1 modules in the PKIX documents instead of the ITU-T > > > documents. The PKIX documents are freely available to all, but the > > > ITU-T documents are not. > > > > This is not true; all ITU-T ASN.1 documents are available at: > > > > http://www.itu.int/ITU-T/studygroups/com10/languages/index.html > > > > Further, the ASN.1 in PKIX docs is not correct (use of UNIVERSAL > > tags), which complicates matters for those using standards-compliant > > compilers. Received: by above.proper.com (8.11.6/8.11.3) id f9BJ65Z13295 for ietf-smime-bks; Thu, 11 Oct 2001 12:06:05 -0700 (PDT) Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9BJ64D13290 for <ietf-smime@imc.org>; Thu, 11 Oct 2001 12:06:04 -0700 (PDT) Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 11 Oct 2001 19:02:50 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA28438 for <ietf-smime@imc.org>; Thu, 11 Oct 2001 15:06:01 -0400 (EDT) Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id PAA25778 for <ietf-smime@imc.org>; Thu, 11 Oct 2001 15:06:00 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQWV38>; Thu, 11 Oct 2001 15:05:55 -0400 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.89]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQWV3Z; Thu, 11 Oct 2001 15:05:50 -0400 From: "Housley, Russ" <rhousley@rsasecurity.com> To: aram@pacbell.net Cc: ietf-smime@imc.org Message-Id: <5.0.1.4.2.20011011150338.02755728@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Thu, 11 Oct 2001 15:04:59 -0400 Subject: Re: X.509 ASN.1 Modules (was Re: WG Last Call: cmsalg) In-Reply-To: <200110111726109.SM00259@tw-web2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Aram: Thanks. The 1997 version posted here is not the most recent version. While it looks like this site may offer some help in the future, it is lagging behind the times. Russ >Magnus Nystrom wrote: > > ...though of course X.509 ASN.1 modules are not freely available > > (AFAIK), > >Surfing the link for the ASN.1 documents, I ran across the following links: >http://www.itu.int/ITU-T/asn1/database/index.html >http://www.itu.int/ITU-T/asn1/database/itu-t/x/x509/1997/index.html > >Enjoy, >Aram Perez Received: by above.proper.com (8.11.6/8.11.3) id f9BHQ7k08869 for ietf-smime-bks; Thu, 11 Oct 2001 10:26:07 -0700 (PDT) Received: from tw-app.thatweb.com (coloc82-059.singnet.com.sg [165.21.82.59]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9BHQ5D08864 for <ietf-smime@imc.org>; Thu, 11 Oct 2001 10:26:05 -0700 (PDT) Received: from tw-web2 [165.21.82.80] by tw-app.thatweb.com (SMTPD32-7.00) id A62AAC0174; Thu, 11 Oct 2001 17:26:02 +0000 From: aram@pacbell.net To: ietf-smime@imc.org Subject: X.509 ASN.1 Modules (was Re: WG Last Call: cmsalg) Date: Thu, 11 Oct 2001 17:28:18 +0000 X-Mailer: CSMTPConnection v1.3 Reply-To: aram@pacbell.net MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Message-Id: <200110111726109.SM00259@tw-web2> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Magnus Nystrom wrote: > ...though of course X.509 ASN.1 modules are not freely available > (AFAIK), Surfing the link for the ASN.1 documents, I ran across the following links: http://www.itu.int/ITU-T/asn1/database/index.html http://www.itu.int/ITU-T/asn1/database/itu-t/x/x509/1997/index.html Enjoy, Aram Perez _________________________________________________ The simple way to read all your emails at ThatWeb http://www.thatweb.com Received: by above.proper.com (8.11.6/8.11.3) id f9BEnAs26836 for ietf-smime-bks; Thu, 11 Oct 2001 07:49:10 -0700 (PDT) Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9BEn1D26813 for <ietf-smime@imc.org>; Thu, 11 Oct 2001 07:49:02 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 11 Oct 2001 14:45:47 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA01059; Thu, 11 Oct 2001 10:48:52 -0400 (EDT) Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id KAA25771; Thu, 11 Oct 2001 10:48:50 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQWP90>; Thu, 11 Oct 2001 10:48:46 -0400 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.123]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQWP95; Thu, 11 Oct 2001 10:48:40 -0400 From: "Housley, Russ" <rhousley@rsasecurity.com> To: jis@mit.edu, mleech@nortelnetworks.com Cc: ietf-smime@imc.org, scoya@ietf.org Message-Id: <5.0.1.4.2.20011011102704.028ebba0@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Thu, 11 Oct 2001 10:32:22 -0400 Subject: draft-ietf-smime-pkcs1-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Jeff & Marcus: The S/MIME WG is finished with draft-ietf-smime-pkcs1-01.txt. This document that describes countermeasures to the Million Message Attack (MMA) for CMS implementations that support PKCS #1 v1.5. We want to publish this document as an Informational RFC. Title : Preventing the Million Message Attack on CMS Author(s) : E. Rescorla Filename : draft-ietf-smime-pkcs1-01.txt Pages : 5 Date : 24-Sep-01 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-pkcs1-01.txt Russ Received: by above.proper.com (8.11.6/8.11.3) id f9BD8TK19252 for ietf-smime-bks; Thu, 11 Oct 2001 06:08:29 -0700 (PDT) Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9BD8RD19248 for <ietf-smime@imc.org>; Thu, 11 Oct 2001 06:08:27 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 11 Oct 2001 13:05:13 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA19914 for <ietf-smime@imc.org>; Thu, 11 Oct 2001 09:08:27 -0400 (EDT) Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id JAA13433 for <ietf-smime@imc.org>; Thu, 11 Oct 2001 09:08:27 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQWNY3>; Thu, 11 Oct 2001 09:08:22 -0400 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.9]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQWNYL; Thu, 11 Oct 2001 09:08:11 -0400 From: "Housley, Russ" <rhousley@rsasecurity.com> To: "Nystrom, Magnus" <mnystrom@rsasecurity.com> Cc: ietf-smime@imc.org Message-Id: <5.0.1.4.2.20011011090637.028e25b0@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Thu, 11 Oct 2001 09:07:44 -0400 Subject: RE: WG Last Call: cmsalg In-Reply-To: <Pine.WNT.4.31.0110111105180.1168-100000@mnystrom-lap> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Magnus: I think that John was referring to the ASN.1 modules associated with X.509, not the ASN.1 specifications themselves. Russ At 11:10 AM 10/11/2001 +0200, Magnus Nystrom wrote: >John Pawling wrote: > >[...] > > I agree with Jim Schaad that the S/MIME specs should reference > > the ASN.1 modules in the PKIX documents instead of the ITU-T > > documents. The PKIX documents are freely available to all, but the > > ITU-T documents are not. > >This is not true; all ITU-T ASN.1 documents are available at: > >http://www.itu.int/ITU-T/studygroups/com10/languages/index.html > >Further, the ASN.1 in PKIX docs is not correct (use of UNIVERSAL >tags), which complicates matters for those using standards-compliant >compilers. > >BR, >-- Magnus Received: by above.proper.com (8.11.6/8.11.3) id f9BCSIY16250 for ietf-smime-bks; Thu, 11 Oct 2001 05:28:18 -0700 (PDT) Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9BCSFD16239 for <ietf-smime@imc.org>; Thu, 11 Oct 2001 05:28:15 -0700 (PDT) Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 11 Oct 2001 12:25:01 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA16694 for <ietf-smime@imc.org>; Thu, 11 Oct 2001 08:28:16 -0400 (EDT) Received: from spirit.dynas.se (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with SMTP id IAA09957 for <ietf-smime@imc.org>; Thu, 11 Oct 2001 08:28:14 -0400 (EDT) Received: (qmail 15044 invoked from network); 11 Oct 2001 12:28:14 -0000 Received: from mnystrom-lap.d.dynas.se (HELO mnystrom-lap) (172.16.13.214) by spirit.dynas.se with SMTP; 11 Oct 2001 12:28:14 -0000 Date: Thu, 11 Oct 2001 14:29:19 +0200 (W. Europe Daylight Time) From: Magnus Nystrom <magnus@rsasecurity.com> Reply-To: =?iso-8859-1?Q?Magnus_Nystr=F6m?= <magnus@dynas.se> To: <ietf-smime@imc.org> Subject: RE: WG Last Call: cmsalg In-Reply-To: <Pine.WNT.4.31.0110111105180.1168-100000@mnystrom-lap> Message-ID: <Pine.WNT.4.31.0110111428160.1168-100000@mnystrom-lap> X-X-Sender: magnus@spirit.dynas.se MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> ...though of course X.509 ASN.1 modules are not freely available (AFAIK), Sorry for any confusion, -- Magnus On Thu, 11 Oct 2001, Magnus Nystrom wrote: > John Pawling wrote: > > [...] > > I agree with Jim Schaad that the S/MIME specs should reference > > the ASN.1 modules in the PKIX documents instead of the ITU-T > > documents. The PKIX documents are freely available to all, but the > > ITU-T documents are not. > > This is not true; all ITU-T ASN.1 documents are available at: > > http://www.itu.int/ITU-T/studygroups/com10/languages/index.html > > Further, the ASN.1 in PKIX docs is not correct (use of UNIVERSAL > tags), which complicates matters for those using standards-compliant > compilers. Received: by above.proper.com (8.11.6/8.11.3) id f9B99qp04525 for ietf-smime-bks; Thu, 11 Oct 2001 02:09:52 -0700 (PDT) Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9B99nD04513 for <ietf-smime@imc.org>; Thu, 11 Oct 2001 02:09:49 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 11 Oct 2001 09:06:34 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id FAA02930 for <ietf-smime@imc.org>; Thu, 11 Oct 2001 05:09:48 -0400 (EDT) Received: from spirit.dynas.se (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with SMTP id FAA23855 for <ietf-smime@imc.org>; Thu, 11 Oct 2001 05:09:47 -0400 (EDT) Received: (qmail 3083 invoked from network); 11 Oct 2001 09:09:46 -0000 Received: from mnystrom-lap.d.dynas.se (HELO mnystrom-lap) (172.16.13.214) by spirit.dynas.se with SMTP; 11 Oct 2001 09:09:46 -0000 Date: Thu, 11 Oct 2001 11:10:52 +0200 (W. Europe Daylight Time) From: Magnus Nystrom <magnus@rsasecurity.com> Reply-To: =?iso-8859-1?Q?Magnus_Nystr=F6m?= <magnus@dynas.se> To: <ietf-smime@imc.org> Subject: RE: WG Last Call: cmsalg Message-ID: <Pine.WNT.4.31.0110111105180.1168-100000@mnystrom-lap> X-X-Sender: magnus@spirit.dynas.se MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> John Pawling wrote: [...] > I agree with Jim Schaad that the S/MIME specs should reference > the ASN.1 modules in the PKIX documents instead of the ITU-T > documents. The PKIX documents are freely available to all, but the > ITU-T documents are not. This is not true; all ITU-T ASN.1 documents are available at: http://www.itu.int/ITU-T/studygroups/com10/languages/index.html Further, the ASN.1 in PKIX docs is not correct (use of UNIVERSAL tags), which complicates matters for those using standards-compliant compilers. BR, -- Magnus Received: by above.proper.com (8.11.6/8.11.3) id f99F7EQ18640 for ietf-smime-bks; Tue, 9 Oct 2001 08:07:14 -0700 (PDT) Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f99F7DD18636 for <ietf-smime@imc.org>; Tue, 9 Oct 2001 08:07:13 -0700 (PDT) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <43TPWZ9C>; Tue, 9 Oct 2001 11:13:31 -0400 Message-ID: <0B95FB5619B3D411817E006008A59259B51C93@wfhqex06.gfgsi.com> From: "Pawling, John" <John.Pawling@GetronicsGov.com> To: ietf-smime@imc.org Subject: RE: WG Last Call: cmsalg Date: Tue, 9 Oct 2001 11:13:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> All, I vote for option 3: "Use PKIX for everything except for v1 attribute certificates; define v1 attribute certificates in the rfc2630bis appendix." I agree with Jim Schaad that the S/MIME specs should reference the ASN.1 modules in the PKIX documents instead of the ITU-T documents. The PKIX documents are freely available to all, but the ITU-T documents are not. To my knowledge, RFC 2630 is the only IETF spec that uses the v1 attribute certificate syntax, so I agree with Russ Housley that the v1 attribute certificate syntax should be included in a rfc2630bis appendix. The S/MIME Freeware Library can ASN.1 encode and decode signedData and envelopedData content types that include v1 attribute certificates. I don't know of any operational use of v1 attribute certificates in signedData and envelopedData content types. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== Received: by above.proper.com (8.11.6/8.11.3) id f993tkr24576 for ietf-smime-bks; Mon, 8 Oct 2001 20:55:46 -0700 (PDT) Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f993thD24572 for <ietf-smime@imc.org>; Mon, 8 Oct 2001 20:55:43 -0700 (PDT) Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id QAA11509; Tue, 9 Oct 2001 16:55:40 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id QAA349970; Tue, 9 Oct 2001 16:55:40 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Tue, 9 Oct 2001 16:55:40 +1300 (NZDT) Message-ID: <200110090355.QAA349970@ruru.cs.auckland.ac.nz> From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: ejnorman@doit.wisc.edu, ietf-smime@imc.org Subject: Re: Encryption Cert OID Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Eric Norman <ejnorman@doit.wisc.edu> writes: >It's an OID that's used by Outlook Express to include the senders preferred >encryption key among the bunch of certificates that are sent in a PKCS7 >signedData structure. The OID is 1.3.6.1.4.1.311.16.4 (seems to be in >Microsoft's arc). It is used as an authenticated attribute; the idea seems to >be the same as SMIMEEncryptionKeyPreference (OID = 1.2.840.113549.1.9.16.2.11). >The syntax is sligtly different; it "points to" the actual certificate with >only IssuerAndSerialNumber; i.e. no CHOICE; no IMPLICIT tag. It looks like you're using an old version of dumpasn1, this is already present in the config: -- Snip -- # This is just the normal issuerAndSerialNumber but with a MS-specific OID. # Apparently it's used for CryptEncode/DecodeObject, whatever that is. OID = 06 0A 2B 06 01 04 01 82 37 10 04 Comment = Microsoft attribute Description = microsoftRecipientInfo (1 3 6 1 4 1 311 16 4) -- Snip -- >There's an OID that seems like it should appear in >http://www.imc.org/ietf-smime/other-smime-oids.asn I think that's reserved specifically for S/MIME-related OIDs, not for any random OID which a vendor might choose to invent. Peter. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9924YJ22704 for ietf-smime-bks; Mon, 8 Oct 2001 19:04:34 -0700 (PDT) Received: from imap1.doit.wisc.edu (imap1.doit.wisc.edu [144.92.9.75]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9924XD22700 for <ietf-smime@imc.org>; Mon, 8 Oct 2001 19:04:34 -0700 (PDT) Received: from [128.104.19.109] (HELO holstein.doit.wisc.edu) by imap1.doit.wisc.edu (CommuniGate Pro SMTP 3.3) with ESMTP id 10530003 for ietf-smime@imc.org; Mon, 08 Oct 2001 21:04:36 -0500 Date: Mon, 8 Oct 2001 21:04:36 -0500 (CDT) From: Eric Norman <ejnorman@doit.wisc.edu> To: SMIME list <ietf-smime@imc.org> Subject: Encryption Cert OID Message-ID: <Pine.A41.4.10.10110082037231.10484-100000@holstein.doit.wisc.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> There's an OID that seems like it should appear in http://www.imc.org/ietf-smime/other-smime-oids.asn It's an OID that's used by Outlook Express to include the senders preferred encryption key among the bunch of certificates that are sent in a PKCS7 signedData structure. The OID is 1.3.6.1.4.1.311.16.4 (seems to be in Microsoft's arc). It is used as an authenticated attribute; the idea seems to be the same as SMIMEEncryptionKeyPreference (OID = 1.2.840.113549.1.9.16.2.11). The syntax is sligtly different; it "points to" the actual certificate with only IssuerAndSerialNumber; i.e. no CHOICE; no IMPLICIT tag. I have no idea whether it's peculiar to Outlook Express or also used in Outlook or any other details. For gory details, here's a snippet from (a slightly modified) Peter Gutmann's dumpasn1: 3829 30 201:g . . . . . . SEQUENCE { 3832 06 9:h . . . . . . . OBJECT IDENTIFIER '1 3 6 1 4 1 311 16 4' 3843 31 187:h . . . . . . . SET { 3846 30 184:i . . . . . . . . SEQUENCE { 3849 30 177:j . . . . . . . . . SEQUENCE { 3852 31 11:k . . . . . . . . . . SET { 3854 30 9:l . . . . . . . . . . . SEQUENCE { 3856 06 3:m . . . . . . . . . . . . OBJECT IDENTIFIER countryName (2 5 4 6) 3861 13 2:m . . . . . . . . . . . . PrintableString 'US' :l . . . . . . . . . . . } :k . . . . . . . . . . } 3865 31 18:k . . . . . . . . . . SET { 3867 30 16:l . . . . . . . . . . . SEQUENCE { 3869 06 3:m . . . . . . . . . . . . OBJECT IDENTIFIER : . . . . . . . . . . . . . stateOrProvinceName (2 5 4 8) 3874 13 9:m . . . . . . . . . . . . PrintableString 'Wisconsin' :l . . . . . . . . . . . } :k . . . . . . . . . . } 3885 31 16:k . . . . . . . . . . SET { 3887 30 14:l . . . . . . . . . . . SEQUENCE { 3889 06 3:m . . . . . . . . . . . . OBJECT IDENTIFIER localityName (2 5 4 7) 3894 13 7:m . . . . . . . . . . . . PrintableString 'Madison' :l . . . . . . . . . . . } :k . . . . . . . . . . } 3903 31 32:k . . . . . . . . . . SET { 3905 30 30:l . . . . . . . . . . . SEQUENCE { 3907 06 3:m . . . . . . . . . . . . OBJECT IDENTIFIER : . . . . . . . . . . . . . organizationName (2 5 4 10) 3912 13 23:m . . . . . . . . . . . . PrintableString 'University of Wisconsin' :l . . . . . . . . . . . } :k . . . . . . . . . . } 3937 31 43:k . . . . . . . . . . SET { 3939 30 41:l . . . . . . . . . . . SEQUENCE { 3941 06 3:m . . . . . . . . . . . . OBJECT IDENTIFIER : . . . . . . . . . . . . . organizationalUnitName (2 5 4 11) 3946 13 34:m . . . . . . . . . . . . PrintableString 'Division of Information Technology' :l . . . . . . . . . . . } :k . . . . . . . . . . } 3982 31 45:k . . . . . . . . . . SET { 3984 30 43:l . . . . . . . . . . . SEQUENCE { 3986 06 3:m . . . . . . . . . . . . OBJECT IDENTIFIER commonName (2 5 4 3) 3991 13 36:m . . . . . . . . . . . . PrintableString 'UW Certificate Services -- 20000529A' :l . . . . . . . . . . . } :k . . . . . . . . . . } :j . . . . . . . . . } 4029 02 2:j . . . . . . . . . INTEGER 509 :i . . . . . . . . } :h . . . . . . . } :g . . . . . . } Eric Norman "I like to stand on the shoulders of the giants that have gone before me. It is the only way I can see beyond the pile of dung that they left behind." Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f990bn420963 for ietf-smime-bks; Mon, 8 Oct 2001 17:37:49 -0700 (PDT) Received: from femail25.sdc1.sfba.home.com (femail25.sdc1.sfba.home.com [24.254.60.15]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f990bmD20957; Mon, 8 Oct 2001 17:37:48 -0700 (PDT) Received: from revelation ([65.4.166.11]) by femail25.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20011009003745.OSPP11797.femail25.sdc1.sfba.home.com@revelation>; Mon, 8 Oct 2001 17:37:45 -0700 Reply-To: <jimsch@exmsft.com> From: "Jim Schaad" <jimsch@nwlink.com> To: "'Paul Hoffman / IMC'" <phoffman@imc.org>, "'Housley, Russ'" <rhousley@rsasecurity.com> Cc: <ietf-smime@imc.org> Subject: RE: WG Last Call: cmsalg Date: Mon, 8 Oct 2001 17:37:48 -0700 Message-ID: <006a01c1505a$9f523c50$0c00a8c0@soaringhawk.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <p0510030db7e7ed7ef568@[165.227.249.20]> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Paul, No PKIX document should ever need to reference the v1 attribute ASN.1. The problem is that the current attribute certificate draft in the PKIX group uses the v2 attribute certificate ASN.1, while CMS originally referenced the v1 attribute certificate ASN.1. I don't think that anybody actually implemented anything that uses the v1 attr certificates, but Russ obviously feels that the ASN.1 should be available in the event that anybody ever needs it under the same availability as the rest of the ASN.1. (This is not my position, since I don't think anybody implemented and uses it, and it is now marked obsolete, it could be omitted entirely and those people who need it can search for it.) Thus I don't think that anybody would ever end up needing to refer to the ASN.1 unless they already are, and no PKIX documents that I know of do so. Jim > -----Original Message----- > From: Paul Hoffman / IMC [mailto:phoffman@imc.org] > Sent: Monday, October 08, 2001 4:57 PM > To: Housley, Russ; jimsch@exmsft.com > Cc: ietf-smime@imc.org > Subject: RE: WG Last Call: cmsalg > > > At 5:29 PM -0400 10/8/01, Housley, Russ wrote: > >I would certainly get the ASN.1 checked to make sure that it > >compiles before posting the updated draft in response to IETF Last > >Call. > > > >Alternative #3 is the only one that we both like. I would like to > >hear from others. > > OK, I'll chime in. Why is this the job of S/MIME? Shouldn't that > importing be being done in PKIX? Isn't it at least as valuable to > them as it is to us? > > We could get into a silly state where some PKIX documents refer to an > S/MIME RFC because it has the v1 ASN.1 they want in it. > > --Paul Hoffman, Director > --Internet Mail Consortium > Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f98Nw0P20044 for ietf-smime-bks; Mon, 8 Oct 2001 16:58:00 -0700 (PDT) Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f98NvuD20038; Mon, 8 Oct 2001 16:57:56 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: <p0510030db7e7ed7ef568@[165.227.249.20]> In-Reply-To: <5.0.1.4.2.20011008172640.0486cc48@exna07.securitydynamics.com> References: <5.0.1.4.2.20011008133128.00b0fbe0@exna07.securitydynamics.com> <5.0.1.4.2.20011008172640.0486cc48@exna07.securitydynamics.com> Date: Mon, 8 Oct 2001 16:57:26 -0700 To: "Housley, Russ" <rhousley@rsasecurity.com>, jimsch@exmsft.com From: Paul Hoffman / IMC <phoffman@imc.org> Subject: RE: WG Last Call: cmsalg Cc: ietf-smime@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> At 5:29 PM -0400 10/8/01, Housley, Russ wrote: >I would certainly get the ASN.1 checked to make sure that it >compiles before posting the updated draft in response to IETF Last >Call. > >Alternative #3 is the only one that we both like. I would like to >hear from others. OK, I'll chime in. Why is this the job of S/MIME? Shouldn't that importing be being done in PKIX? Isn't it at least as valuable to them as it is to us? We could get into a silly state where some PKIX documents refer to an S/MIME RFC because it has the v1 ASN.1 they want in it. --Paul Hoffman, Director --Internet Mail Consortium Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f98Le5l16682 for ietf-smime-bks; Mon, 8 Oct 2001 14:40:05 -0700 (PDT) Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f98Le3D16677 for <ietf-smime@imc.org>; Mon, 8 Oct 2001 14:40:03 -0700 (PDT) Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 8 Oct 2001 21:36:53 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA21490 for <ietf-smime@imc.org>; Mon, 8 Oct 2001 17:40:05 -0400 (EDT) Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id RAA27705 for <ietf-smime@imc.org>; Mon, 8 Oct 2001 17:40:05 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQVFSC>; Mon, 8 Oct 2001 17:40:01 -0400 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.11]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQVFR7; Mon, 8 Oct 2001 17:39:51 -0400 From: "Housley, Russ" <rhousley@rsasecurity.com> To: jimsch@exmsft.com Cc: ietf-smime@imc.org Message-Id: <5.0.1.4.2.20011008172640.0486cc48@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Mon, 08 Oct 2001 17:29:49 -0400 Subject: RE: WG Last Call: cmsalg In-Reply-To: <006401c1502a$e3db8eb0$0c00a8c0@soaringhawk.net> References: <5.0.1.4.2.20011008133128.00b0fbe0@exna07.securitydynamics.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Jim: I would certainly get the ASN.1 checked to make sure that it compiles before posting the updated draft in response to IETF Last Call. Alternative #3 is the only one that we both like. I would like to hear from others. Russ At 11:56 AM 10/8/2001 -0700, Jim Schaad wrote: >Russ, > >I would have a strong prefrence for either 2 or 3. (Actually 3 would be >nice since I would then have the ASN.1 for a v1 attribute certificate.) >I disagree that this is a simple editorial change as we need to get >compiles dones of the ASN.1 before it is finished and I don't want to >try that in the 48 hour editors area. In the past changes to the ASN.1 >modules have been deemed non-editorial changes. > >jim > > > -----Original Message----- > > From: Housley, Russ [mailto:rhousley@rsasecurity.com] > > Sent: Monday, October 08, 2001 10:50 AM > > To: jimsch@exmsft.com > > Cc: ietf-smime@imc.org > > Subject: RE: WG Last Call: cmsalg > > > > > > Jim: > > > > As you pointed out in a message last week, the ASN.1 modules in both > > rfc2630bis and cmsalg still include IMPORT statements from ITU-T > > documents. You recommended that these IMPORT statements > > reference the > > ASN.1 modules in the PKIX documents instead. I did not make > > this change > > because there are no PKIX documents that include the definition of v1 > > attribute certificates. > > > > As I see it, we have three choices: > > 1. Do nothing. Continue to IMPORT from ITU-T documents. > > 2. Use PKIX for everything except for v1 attribute > > certificates; IMPORT v1 > > attribute certificates from ITU-T. > > 3. Use PKIX for everything except for v1 attribute > > certificates; define v1 > > attribute certificates in the rfc2630bis appendix. > > > > I prefer either 1 or 3, so that all of the IMPORTS come from > > the same class > > of documents (RFC or ITU-T Recommendation). > > > > If we choose 1, then no further action is needed. > > > > If we choose 3, then I would like to make these editorial > > changes when any > > other IETF Last Call comments are handled. I consider this > > an editorial > > change since it does not impact any implementation. No bits > > on the wire > > are impacted. > > > > Russ > > > > At 07:43 PM 8/21/2001 -0700, Jim Schaad wrote: > > >[JLS] I would request that the PKIX module be used rather than the > > >X.509 since that is more widely available. > > Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f98Iu8J12645 for ietf-smime-bks; Mon, 8 Oct 2001 11:56:08 -0700 (PDT) Received: from femail27.sdc1.sfba.home.com (femail27.sdc1.sfba.home.com [24.254.60.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f98Iu6D12640 for <ietf-smime@imc.org>; Mon, 8 Oct 2001 11:56:07 -0700 (PDT) Received: from revelation ([65.4.166.11]) by femail27.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20011008185604.EYNP10548.femail27.sdc1.sfba.home.com@revelation>; Mon, 8 Oct 2001 11:56:04 -0700 Reply-To: <jimsch@exmsft.com> From: "Jim Schaad" <jimsch@nwlink.com> To: "'Housley, Russ'" <rhousley@rsasecurity.com> Cc: <ietf-smime@imc.org> Subject: RE: WG Last Call: cmsalg Date: Mon, 8 Oct 2001 11:56:07 -0700 Message-ID: <006401c1502a$e3db8eb0$0c00a8c0@soaringhawk.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <5.0.1.4.2.20011008133128.00b0fbe0@exna07.securitydynamics.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Russ, I would have a strong prefrence for either 2 or 3. (Actually 3 would be nice since I would then have the ASN.1 for a v1 attribute certificate.) I disagree that this is a simple editorial change as we need to get compiles dones of the ASN.1 before it is finished and I don't want to try that in the 48 hour editors area. In the past changes to the ASN.1 modules have been deemed non-editorial changes. jim > -----Original Message----- > From: Housley, Russ [mailto:rhousley@rsasecurity.com] > Sent: Monday, October 08, 2001 10:50 AM > To: jimsch@exmsft.com > Cc: ietf-smime@imc.org > Subject: RE: WG Last Call: cmsalg > > > Jim: > > As you pointed out in a message last week, the ASN.1 modules in both > rfc2630bis and cmsalg still include IMPORT statements from ITU-T > documents. You recommended that these IMPORT statements > reference the > ASN.1 modules in the PKIX documents instead. I did not make > this change > because there are no PKIX documents that include the definition of v1 > attribute certificates. > > As I see it, we have three choices: > 1. Do nothing. Continue to IMPORT from ITU-T documents. > 2. Use PKIX for everything except for v1 attribute > certificates; IMPORT v1 > attribute certificates from ITU-T. > 3. Use PKIX for everything except for v1 attribute > certificates; define v1 > attribute certificates in the rfc2630bis appendix. > > I prefer either 1 or 3, so that all of the IMPORTS come from > the same class > of documents (RFC or ITU-T Recommendation). > > If we choose 1, then no further action is needed. > > If we choose 3, then I would like to make these editorial > changes when any > other IETF Last Call comments are handled. I consider this > an editorial > change since it does not impact any implementation. No bits > on the wire > are impacted. > > Russ > > At 07:43 PM 8/21/2001 -0700, Jim Schaad wrote: > >[JLS] I would request that the PKIX module be used rather than the > >X.509 since that is more widely available. > Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f98IDxK11484 for ietf-smime-bks; Mon, 8 Oct 2001 11:13:59 -0700 (PDT) Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f98IDrD11480 for <ietf-smime@imc.org>; Mon, 8 Oct 2001 11:13:53 -0700 (PDT) Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 8 Oct 2001 18:10:42 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA06355 for <ietf-smime@imc.org>; Mon, 8 Oct 2001 14:13:55 -0400 (EDT) Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id OAA12638 for <ietf-smime@imc.org>; Mon, 8 Oct 2001 14:13:54 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQVCSM>; Mon, 8 Oct 2001 14:13:50 -0400 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.69]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQVCSL; Mon, 8 Oct 2001 14:13:48 -0400 From: "Housley, Russ" <rhousley@rsasecurity.com> To: jimsch@exmsft.com Cc: ietf-smime@imc.org Message-Id: <5.0.1.4.2.20011008133128.00b0fbe0@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Mon, 08 Oct 2001 13:50:06 -0400 Subject: RE: WG Last Call: cmsalg In-Reply-To: <000001c12ab4$34b15000$0c00a8c0@soaringhawk.net> References: <5.0.1.4.2.20010820174103.026f1df0@exna07.securitydynamics.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Jim: As you pointed out in a message last week, the ASN.1 modules in both rfc2630bis and cmsalg still include IMPORT statements from ITU-T documents. You recommended that these IMPORT statements reference the ASN.1 modules in the PKIX documents instead. I did not make this change because there are no PKIX documents that include the definition of v1 attribute certificates. As I see it, we have three choices: 1. Do nothing. Continue to IMPORT from ITU-T documents. 2. Use PKIX for everything except for v1 attribute certificates; IMPORT v1 attribute certificates from ITU-T. 3. Use PKIX for everything except for v1 attribute certificates; define v1 attribute certificates in the rfc2630bis appendix. I prefer either 1 or 3, so that all of the IMPORTS come from the same class of documents (RFC or ITU-T Recommendation). If we choose 1, then no further action is needed. If we choose 3, then I would like to make these editorial changes when any other IETF Last Call comments are handled. I consider this an editorial change since it does not impact any implementation. No bits on the wire are impacted. Russ At 07:43 PM 8/21/2001 -0700, Jim Schaad wrote: >[JLS] I would request that the PKIX module be used rather than the >X.509 since that is more widely available. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f98ALRR11698 for ietf-smime-bks; Mon, 8 Oct 2001 03:21:27 -0700 (PDT) Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f98ALPD11693 for <ietf-smime@imc.org>; Mon, 8 Oct 2001 03:21:25 -0700 (PDT) Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id XAA19451 for <ietf-smime@imc.org>; Mon, 8 Oct 2001 23:21:20 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id XAA324661 for ietf-smime@imc.org; Mon, 8 Oct 2001 23:21:19 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Mon, 8 Oct 2001 23:21:19 +1300 (NZDT) Message-ID: <200110081021.XAA324661@ruru.cs.auckland.ac.nz> From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org Subject: RE: Questions on AuthenticatedData Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> I wrote: >Well, there are three major protocols which use HMAC, namely IPsec, SSL/TLS, >and SSHv2 (aka "SSL done with SSH packet formats"). If macSize is the size of >the generated MAC (128 bits for HMAC-MD5, 160 bits for HMAC-SHA) then SSL uses >a key of size macSize, SSHv2 uses a key of size macSize, and I dunno about >IPsec (the RFCs are silent on this, and I've never implemented it so I don't >know what people use). Before this ends up in a spec somewhere as "Anyone who doesn't use a <macSize> key will be banished to van Diemens Land with only an ASN.1 dump for companionship", does it actually matter what key size you use? Since you can wrap arbitrary-length keys, you could certainly include an implementation note to say that the convention is to use keys of size <macSize>, but there's nothing to prevent you from using keys of other lengths (the SSHv2 spec actually requires the use of 128-bit keys, but I guess the <SSH-the-company> implementation used 160-bit keys and everyone copied that). In fact the only reason that SSL/TLS and SSHv2 specify a size is because their key derivation process performed after the key exchange part of the protocol handshake generates a whole pile of keying material and it's necessary to fix where one key stops and the next one starts. This isn't an issue with CMS. In fact if you're using a 128-bit AES key from (say) a KeyTransRecipientInfo to MAC and encrypt you'd use 128 bits, if you're using a 3DES key it's your choice between 160 and 192 bits, if all you've got is 64 bits you'd use that. There's no reason to restrict the choice, particularly since you can't control where the keying material is coming from. (Just looking at my own code, I use 128-bit keys for all the HMACs if the user doesn't specify otherwise, mostly because it's "the standard", but they can specify anything from 40 to INT_MAX or thereabouts if they want and it still works). Peter. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f985ODU01359 for ietf-smime-bks; Sun, 7 Oct 2001 22:24:13 -0700 (PDT) Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f985OBD01355 for <ietf-smime@imc.org>; Sun, 7 Oct 2001 22:24:11 -0700 (PDT) Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id SAA15086; Mon, 8 Oct 2001 18:23:37 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id SAA319318; Mon, 8 Oct 2001 18:23:37 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Mon, 8 Oct 2001 18:23:37 +1300 (NZDT) Message-ID: <200110080523.SAA319318@ruru.cs.auckland.ac.nz> From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org, jimsch@exmsft.com, pgut001@cs.aucKland.ac.nz Subject: RE: Questions on AuthenticatedData Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> "Jim Schaad" <jimsch@nwlink.com> writes: >Can you give a few places where this is the convention? It seems counter to >what would be intuitive looking at the Microsoft APIs. This does not mean >that you are not correct, I was just wondering. Well, there are three major protocols which use HMAC, namely IPsec, SSL/TLS, and SSHv2 (aka "SSL done with SSH packet formats"). If macSize is the size of the generated MAC (128 bits for HMAC-MD5, 160 bits for HMAC-SHA) then SSL uses a key of size macSize, SSHv2 uses a key of size macSize, and I dunno about IPsec (the RFCs are silent on this, and I've never implemented it so I don't know what people use). Peter. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f98514700843 for ietf-smime-bks; Sun, 7 Oct 2001 22:01:04 -0700 (PDT) Received: from femail48.sdc1.sfba.home.com (femail48.sdc1.sfba.home.com [24.254.60.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f98513D00838 for <ietf-smime@imc.org>; Sun, 7 Oct 2001 22:01:03 -0700 (PDT) Received: from revelation ([65.4.166.11]) by femail48.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20011008050102.QLCK18018.femail48.sdc1.sfba.home.com@revelation>; Sun, 7 Oct 2001 22:01:02 -0700 Reply-To: <jimsch@exmsft.com> From: "Jim Schaad" <jimsch@nwlink.com> To: "'Peter Gutmann'" <pgut001@cs.aucKland.ac.nz>, <ietf-smime@imc.org>, <jimsch@exmsft.com> Subject: RE: Questions on AuthenticatedData Date: Sun, 7 Oct 2001 22:01:07 -0700 Message-ID: <006001c14fb6$3db133b0$0c00a8c0@soaringhawk.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <200110080145.OAA304238@ruru.cs.auckland.ac.nz> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Peter, Can you give a few places where this is the convention? It seems counter to what would be intuitive looking at the Microsoft APIs. This does not mean that you are not correct, I was just wondering. jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Peter Gutmann > Sent: Sunday, October 07, 2001 6:45 PM > To: ietf-smime@imc.org; jimsch@exmsft.com > Subject: Re: Questions on AuthenticatedData > > > > "Jim Schaad" <jimsch@nwlink.com> writes: > > >1. Should we specify a suggested size for the randomly > generated secret to be > >used for HMAC-SHA1? (The size for HMAC-3DES is fixed at the > size of a 3DES > >key.) > > The convention seems to be to use a 160-bit value (even if > the spec says that > algorithms with variable-length keys use a 128-bit key and > you use that and > then spend half a day trying to figure out why your MACs are > failing when all > the other side tells you is "Bad MAC"). > > Peter. > Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f981kAr26820 for ietf-smime-bks; Sun, 7 Oct 2001 18:46:10 -0700 (PDT) Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f981k8D26816 for <ietf-smime@imc.org>; Sun, 7 Oct 2001 18:46:08 -0700 (PDT) Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id OAA09122; Mon, 8 Oct 2001 14:45:16 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id OAA304238; Mon, 8 Oct 2001 14:45:15 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Mon, 8 Oct 2001 14:45:15 +1300 (NZDT) Message-ID: <200110080145.OAA304238@ruru.cs.auckland.ac.nz> From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org, jimsch@exmsft.com Subject: Re: Questions on AuthenticatedData Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> "Jim Schaad" <jimsch@nwlink.com> writes: >1. Should we specify a suggested size for the randomly generated secret to be >used for HMAC-SHA1? (The size for HMAC-3DES is fixed at the size of a 3DES >key.) The convention seems to be to use a 160-bit value (even if the spec says that algorithms with variable-length keys use a 128-bit key and you use that and then spend half a day trying to figure out why your MACs are failing when all the other side tells you is "Bad MAC"). Peter. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f980uur25904 for ietf-smime-bks; Sun, 7 Oct 2001 17:56:56 -0700 (PDT) Received: from femail31.sdc1.sfba.home.com (femail31.sdc1.sfba.home.com [24.254.60.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f980utD25900 for <ietf-smime@imc.org>; Sun, 7 Oct 2001 17:56:55 -0700 (PDT) Received: from revelation ([65.4.166.11]) by femail31.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20011008005653.MMBQ28498.femail31.sdc1.sfba.home.com@revelation> for <ietf-smime@imc.org>; Sun, 7 Oct 2001 17:56:53 -0700 Reply-To: <jimsch@exmsft.com> From: "Jim Schaad" <jimsch@nwlink.com> To: <ietf-smime@imc.org> Subject: Questions on AuthenticatedData Date: Sun, 7 Oct 2001 17:56:58 -0700 Message-ID: <005f01c14f94$22361b90$0c00a8c0@soaringhawk.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> I have just started an implemenation for AutenticatedData and have the following questions: 1. Should we specify a suggested size for the randomly generated secret to be used for HMAC-SHA1? (The size for HMAC-3DES is fixed at the size of a 3DES key.) 2. What key wrap algorithm should I use for wrapping the secret for an HMAC-SHA1 secret? I can see myself generating a 512 bit secret for the MAC operation, now I need to wrap it in a 3DES, RC2 or AES key. What is the proper way of doing this? 3. Does the answer for 2 imply that we want the lengths for 1 to be the length of a defined content encrytion algorithm key? Jim Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f96GDZ226564 for ietf-smime-bks; Sat, 6 Oct 2001 09:13:35 -0700 (PDT) Received: from hawaii.deming.com (hawaii.deming.com [208.236.41.139]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f96GDYD26557 for <ietf-smime@imc.org>; Sat, 6 Oct 2001 09:13:34 -0700 (PDT) Received: from 208.236.41.137 by hawaii.deming.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Sat, 06 Oct 2001 09:13:18 -0700 X-Server-Uuid: F4BC6258-86A5-40F3-9714-0CF63E081F09 Received: by cane.deming.com with Internet Mail Service (5.5.2650.21) id <R9KF64FK>; Sat, 6 Oct 2001 09:13:17 -0700 Message-ID: <01FF24001403D011AD7B00A024BC53C5BD1708@cane.deming.com> From: "Blake Ramsdell" <blaker@tumbleweed.com> To: "'James M Galvin '" <galvin@acm.org>, "'Housley, Russ '" <rhousley@rsasecurity.com> cc: "''ietf-smime@imc.org' '" <ietf-smime@imc.org> Subject: RE: multipart/signed clarifications Date: Sat, 6 Oct 2001 09:13:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-WSS-ID: 17A1F2147562-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> It's fine with me -- let's see if there are any other suggestions or comments. Blake -----Original Message----- From: James M Galvin To: Housley, Russ; Blake Ramsdell Cc: 'ietf-smime@imc.org' Sent: 10/6/2001 7:37 AM Subject: Re: multipart/signed clarifications I like #2. As one of the authors of 1847 I've got a short list of updates that could also be incorporated. I'm volunteering to do this if you agree. Jim -- James M. Galvin <galvin@acm.org> On Fri, 5 Oct 2001, Housley, Russ wrote: Date: Fri, 05 Oct 2001 16:51:09 -0400 From: "Housley, Russ" <rhousley@rsasecurity.com> To: Blake Ramsdell <blaker@tumbleweed.com> Cc: "'ietf-smime@imc.org'" <ietf-smime@imc.org> Subject: Re: multipart/signed clarifications Blake: I like #1, as long as it includes some examples. Russ At 11:48 AM 10/5/2001 -0700, Blake Ramsdell wrote: >Siegfried Schmitt mentioned in private email that using S/MIME with detached >signatures (multipart/signed) could use some clarification, and I agree. >There is always confusion about what exact data needs to be digested in >order to create the signature. However, this is a problem that transcends >all multipart/signed implementations, and is not just limited to S/MIME. > >Off the top of my head, I see some options: > >1. Create a new draft to supplement RFC1847 ("implementation notes for >security multiparts") > >2. Reissue RFC1847 with modifications > >3. Stick some more verbiage in the new MSG draft, along with some examples > >These are in order of my personal preference. I know that there are >implementors out there that can contribute to this, and I know that OpenPGP >uses RFC1847 also, so a separate draft benefits everyone. > >Any comments? > >Blake >-- >Blake C. Ramsdell, Tumbleweed Communications >Voice +1 425 376 0225 x103 Fax +1 425 376 0915 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f96EWgB16000 for ietf-smime-bks; Sat, 6 Oct 2001 07:32:42 -0700 (PDT) Received: from one.elistx.com (one.elistx.com [209.116.252.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f96EWfD15996 for <ietf-smime@imc.org>; Sat, 6 Oct 2001 07:32:41 -0700 (PDT) Received: from two.elistx.com (two.elistx.com [209.116.254.209]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0GKS00BBGGI3NI@eListX.com> for ietf-smime@imc.org; Sat, 06 Oct 2001 10:34:52 -0400 (EDT) Date: Sat, 06 Oct 2001 10:37:07 -0400 (EDT) From: James M Galvin <galvin@acm.org> Subject: Re: multipart/signed clarifications In-reply-to: <5.0.1.4.2.20011005165044.00b01770@exna07.securitydynamics.com> X-Sender: galvin@two.elistx.com To: "Housley, Russ" <rhousley@rsasecurity.com>, Blake Ramsdell <blaker@tumbleweed.com> Cc: "'ietf-smime@imc.org'" <ietf-smime@imc.org> Message-id: <Pine.BSF.4.21.0110061034530.9254-100000@two.elistx.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> I like #2. As one of the authors of 1847 I've got a short list of updates that could also be incorporated. I'm volunteering to do this if you agree. Jim -- James M. Galvin <galvin@acm.org> On Fri, 5 Oct 2001, Housley, Russ wrote: Date: Fri, 05 Oct 2001 16:51:09 -0400 From: "Housley, Russ" <rhousley@rsasecurity.com> To: Blake Ramsdell <blaker@tumbleweed.com> Cc: "'ietf-smime@imc.org'" <ietf-smime@imc.org> Subject: Re: multipart/signed clarifications Blake: I like #1, as long as it includes some examples. Russ At 11:48 AM 10/5/2001 -0700, Blake Ramsdell wrote: >Siegfried Schmitt mentioned in private email that using S/MIME with detached >signatures (multipart/signed) could use some clarification, and I agree. >There is always confusion about what exact data needs to be digested in >order to create the signature. However, this is a problem that transcends >all multipart/signed implementations, and is not just limited to S/MIME. > >Off the top of my head, I see some options: > >1. Create a new draft to supplement RFC1847 ("implementation notes for >security multiparts") > >2. Reissue RFC1847 with modifications > >3. Stick some more verbiage in the new MSG draft, along with some examples > >These are in order of my personal preference. I know that there are >implementors out there that can contribute to this, and I know that OpenPGP >uses RFC1847 also, so a separate draft benefits everyone. > >Any comments? > >Blake >-- >Blake C. Ramsdell, Tumbleweed Communications >Voice +1 425 376 0225 x103 Fax +1 425 376 0915 Received: by above.proper.com (8.11.6/8.11.3) id f95MhKN18300 for ietf-smime-bks; Fri, 5 Oct 2001 15:43:20 -0700 (PDT) Received: from hawaii.deming.com (hawaii.deming.com [208.236.41.139]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f95MhJD18296 for <ietf-smime@imc.org>; Fri, 5 Oct 2001 15:43:19 -0700 (PDT) Received: from 208.236.41.137 by hawaii.deming.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Fri, 05 Oct 2001 15:43:09 -0700 X-Server-Uuid: F4BC6258-86A5-40F3-9714-0CF63E081F09 Received: by cane.deming.com with Internet Mail Service (5.5.2650.21) id <R9KF6T04>; Fri, 5 Oct 2001 15:43:09 -0700 Message-ID: <01FF24001403D011AD7B00A024BC53C5BD16FB@cane.deming.com> From: "Blake Ramsdell" <blaker@tumbleweed.com> To: "'Housley, Russ'" <rhousley@rsasecurity.com> cc: "'ietf-smime@imc.org'" <ietf-smime@imc.org> Subject: RE: multipart/signed clarifications Date: Fri, 5 Oct 2001 15:43:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-WSS-ID: 17A0E8F77061-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> That's right -- I said "with some examples" for the MSG draft, but not for any of the other options. Yes, there would be examples in all cases to illustrate the exact octets for digesting. I am working on the MSG and CERT drafts right now, but I will do this afterwards at least as a strawman for discussion. Blake -----Original Message----- From: Housley, Russ [mailto:rhousley@rsasecurity.com] Sent: Friday, October 05, 2001 1:51 PM To: Blake Ramsdell Cc: 'ietf-smime@imc.org' Subject: Re: multipart/signed clarifications Blake: I like #1, as long as it includes some examples. Russ At 11:48 AM 10/5/2001 -0700, Blake Ramsdell wrote: >Siegfried Schmitt mentioned in private email that using S/MIME with detached >signatures (multipart/signed) could use some clarification, and I agree. >There is always confusion about what exact data needs to be digested in >order to create the signature. However, this is a problem that transcends >all multipart/signed implementations, and is not just limited to S/MIME. > >Off the top of my head, I see some options: > >1. Create a new draft to supplement RFC1847 ("implementation notes for >security multiparts") > >2. Reissue RFC1847 with modifications > >3. Stick some more verbiage in the new MSG draft, along with some examples > >These are in order of my personal preference. I know that there are >implementors out there that can contribute to this, and I know that OpenPGP >uses RFC1847 also, so a separate draft benefits everyone. > >Any comments? > >Blake >-- >Blake C. Ramsdell, Tumbleweed Communications >Voice +1 425 376 0225 x103 Fax +1 425 376 0915 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f95KpQa14557 for ietf-smime-bks; Fri, 5 Oct 2001 13:51:26 -0700 (PDT) Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f95KpOD14553 for <ietf-smime@imc.org>; Fri, 5 Oct 2001 13:51:24 -0700 (PDT) Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 5 Oct 2001 20:48:17 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA12127 for <ietf-smime@imc.org>; Fri, 5 Oct 2001 16:51:26 -0400 (EDT) Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id QAA20356 for <ietf-smime@imc.org>; Fri, 5 Oct 2001 16:51:24 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQ4SXP>; Fri, 5 Oct 2001 16:51:22 -0400 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.18]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQ4SXL; Fri, 5 Oct 2001 16:51:14 -0400 From: "Housley, Russ" <rhousley@rsasecurity.com> To: Blake Ramsdell <blaker@tumbleweed.com> Cc: "'ietf-smime@imc.org'" <ietf-smime@imc.org> Message-Id: <5.0.1.4.2.20011005165044.00b01770@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Fri, 05 Oct 2001 16:51:09 -0400 Subject: Re: multipart/signed clarifications In-Reply-To: <01FF24001403D011AD7B00A024BC53C5BD16EF@cane.deming.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Blake: I like #1, as long as it includes some examples. Russ At 11:48 AM 10/5/2001 -0700, Blake Ramsdell wrote: >Siegfried Schmitt mentioned in private email that using S/MIME with detached >signatures (multipart/signed) could use some clarification, and I agree. >There is always confusion about what exact data needs to be digested in >order to create the signature. However, this is a problem that transcends >all multipart/signed implementations, and is not just limited to S/MIME. > >Off the top of my head, I see some options: > >1. Create a new draft to supplement RFC1847 ("implementation notes for >security multiparts") > >2. Reissue RFC1847 with modifications > >3. Stick some more verbiage in the new MSG draft, along with some examples > >These are in order of my personal preference. I know that there are >implementors out there that can contribute to this, and I know that OpenPGP >uses RFC1847 also, so a separate draft benefits everyone. > >Any comments? > >Blake >-- >Blake C. Ramsdell, Tumbleweed Communications >Voice +1 425 376 0225 x103 Fax +1 425 376 0915 Received: by above.proper.com (8.11.6/8.11.3) id f95Imqq10979 for ietf-smime-bks; Fri, 5 Oct 2001 11:48:52 -0700 (PDT) Received: from hawaii.deming.com (hawaii.deming.com [208.236.41.139]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f95ImpD10975 for <ietf-smime@imc.org>; Fri, 5 Oct 2001 11:48:51 -0700 (PDT) Received: from 208.236.41.137 by hawaii.deming.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Fri, 05 Oct 2001 11:48:35 -0700 X-Server-Uuid: F4BC6258-86A5-40F3-9714-0CF63E081F09 Received: by cane.deming.com with Internet Mail Service (5.5.2650.21) id <R9KF6T5N>; Fri, 5 Oct 2001 11:48:35 -0700 Message-ID: <01FF24001403D011AD7B00A024BC53C5BD16EF@cane.deming.com> From: "Blake Ramsdell" <blaker@tumbleweed.com> To: "'ietf-smime@imc.org'" <ietf-smime@imc.org> Subject: multipart/signed clarifications Date: Fri, 5 Oct 2001 11:48:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-WSS-ID: 17A0DF096671-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Siegfried Schmitt mentioned in private email that using S/MIME with detached signatures (multipart/signed) could use some clarification, and I agree. There is always confusion about what exact data needs to be digested in order to create the signature. However, this is a problem that transcends all multipart/signed implementations, and is not just limited to S/MIME. Off the top of my head, I see some options: 1. Create a new draft to supplement RFC1847 ("implementation notes for security multiparts") 2. Reissue RFC1847 with modifications 3. Stick some more verbiage in the new MSG draft, along with some examples These are in order of my personal preference. I know that there are implementors out there that can contribute to this, and I know that OpenPGP uses RFC1847 also, so a separate draft benefits everyone. Any comments? Blake -- Blake C. Ramsdell, Tumbleweed Communications Voice +1 425 376 0225 x103 Fax +1 425 376 0915 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f94Jxi011479 for ietf-smime-bks; Thu, 4 Oct 2001 12:59:44 -0700 (PDT) Received: from hawaii.deming.com (hawaii.deming.com [208.236.41.139]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f94JxiD11475 for <ietf-smime@imc.org>; Thu, 4 Oct 2001 12:59:44 -0700 (PDT) Received: from 208.236.41.137 by hawaii.deming.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Thu, 04 Oct 2001 12:59:39 -0700 X-Server-Uuid: F4BC6258-86A5-40F3-9714-0CF63E081F09 Received: by cane.deming.com with Internet Mail Service (5.5.2650.21) id <R9KF6T3L>; Thu, 4 Oct 2001 12:59:39 -0700 Message-ID: <01FF24001403D011AD7B00A024BC53C5BD16E7@cane.deming.com> From: "Blake Ramsdell" <blaker@tumbleweed.com> To: "'William Ottaway'" <w.ottaway@eris.dera.gov.uk>, ietf-smime@imc.org Subject: RE: DOMSEC and S/MIME Gateway Protocol comparison Date: Thu, 4 Oct 2001 12:59:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-WSS-ID: 17A260215861-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Bill, thanks very much for doing this summary. One thing that we were initially concerned about was that there was a requirement for triple-wrapping and/or an empty signature layer (SignedData with no SignerInfos). If this requirement is gone, then I believe we can simply make our document an "encrypting-only" profile for DOMSEC. I propose that our current document continue to live, but with the following changes: 1. Refer to DOMSEC in the relevant places in our draft 2. Remove the language about the email address in the certificate, and refer to DOMSEC for this 3. Clarify that the additions that we have specified for handling subdomains, etc. are in addition to DOMSEC (and thus the meat of this profile) The only impact for any existing implementations of our specification would therefore be the recognition of the DOMSEC-specified email address (domain-confidentiality-authority) as opposed to the smg_encryptor email address that we originally specified in our draft. Blake -----Original Message----- From: William Ottaway [mailto:w.ottaway@eris.dera.gov.uk] Sent: Friday, September 21, 2001 6:42 AM To: ietf-smime@imc.org Cc: Blake Ramsdell Subject: DOMSEC and S/MIME Gateway Protocol comparison At the S/MIME WG meeting in London I was tasked to provide a comparison between DOMSEC and the S/MIME Gateway Protocol (draft-ramsdell-enc-smime-gateway-00.txt) in order to start a discussion on whether the gateway draft should be progressed and if so how would it relate to DOMSEC. DOMSEC Summary: - 1) Encryption/Decryption and signing. 2) Defines naming conventions. 3) Defines signature types. 4) Defines membership of a domain. 5) Defines rules for domain signature generation and verification. 6) States how domain encryption/decryption is achieved. 7) Defines domain signature application rules when sending to mail list agents. Gateway Summary: - 1) Encryption/Decryption only. 2) Uses same notation of domain "membership" as DOMSEC. 3) Introduces its own naming convention for the encrypting entities domain certificate, smg_encryptor@domain. DOMSEC defines domain-confidentiality-authority@domain. 4) Introduces a mechanism for identifying multiple domains handled by the gateway. They can be listed in a single certificate or in multiple certificates. 5) Introduces a rule for deciding which recipient domain certificate must be used. 6) Introduces a rule on how the gateway recognises that a message requires encryption (encrypt if have a certificate for the recipients domain). 7) Introduces a rule on when the gateway should decrypt a message (when the gateways public key has been used to encrypt) My view: - DOMSEC defines mechanisms for domain signing and encrypting with out specifying mechanisms or rules that are deemed local to the installation. It is hoped that domain signing and encryption implementations will be compliant with DOMSEC. It is expected that individual installations will provide extra local mechanisms and rules in support of DOMSEC, for example how to decide on which certificate to use, how to decide on whether encryption is required, how certificates are retrieved, whether a domain signature is stripped off before forwarding to the local recipient, whether encryption between the domain boundary and the local recipient is required, etc. The Gateway draft defines mechanisms that are already defined in DOMSEC, such as encryption and naming notation. It also defines mechanisms that may differ between implementations, such as domains that are handled by the gateway may be listed in a single or multiple certificate and rules on which recipient certificate to use when encrypting. I propose that the Gateway draft should be a profile of DOMSEC. Therefore, it should support encryption/decryption as specified in DOMSEC and the DOMSEC naming convention. The Gateway draft would contain those features local to this implementation such as points 4 - 7 in the gateway summary. Bill ____________________________________________________ William Ottaway BSc Hons CEng MBCS, Woodward B009, QinetiQ Tel: +44 (0) 1684 894079 Malvern Technology Centre, Fax: +44 (0) 1684 896660 St. Andrews Road, email: wjottaway@QinetiQ.com Malvern, Worcs, WR14 3PS All opinions are my own. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f94Gm4n04153 for ietf-smime-bks; Thu, 4 Oct 2001 09:48:04 -0700 (PDT) Received: from bcqre.com ([211.177.183.253]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f94GldD04145 for <ietf-smime@imc.org>; Thu, 4 Oct 2001 09:47:39 -0700 (PDT) Received: from bcqre.com ([192.168.13.157]) by bcqre.com (8.11.0/8.11.0) with ESMTP id f94GXqE02260 for <ietf-smime@imc.org>; Fri, 5 Oct 2001 01:33:52 +0900 Message-ID: <3BBC92A7.47BD0ABF@bcqre.com> Date: Fri, 05 Oct 2001 01:47:35 +0900 From: "Chung, KwonSung" <kschung@bcqre.com> Organization: (C)BCQRE X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-smime@imc.org Subject: mime parser Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msBFEF04EFCA88A75D20F17558" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> This is a cryptographically signed message in MIME format. --------------msBFEF04EFCA88A75D20F17558 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Hello all, Can I can a free source code for a mime message parser? If you have or know about it, please let me know also. Thank you. --------------msBFEF04EFCA88A75D20F17558 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 MIIKDQYJKoZIhvcNAQcCoIIJ/jCCCfoCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B5kwggRjMIIDzKADAgECAhBBJbskjkPBWdQ70/WW40CjMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAxMTAwMzAwMDAw MFoXDTAxMTIwMjIzNTk1OVowggEHMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMSYwJAYDVQQLEx1EaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZTEZMBcGA1UEAxQQa3NjaHVuZyAyMDAxMTAwNDEgMB4GCSqGSIb3DQEJARYRa3Nj aHVuZ0BiY3FyZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALrwur7V71u7ZVbM NLreqXg4KrkTL9BwOox2tRVelTQqicKN5qmR5q9e3tvvpxG8tAOpPDL04I9Dtzw2cyTW4tcB CgC3jUaqUVaEJhPqpHu+HqbNnAxQIXxSoF3I71OEMZJ6Tm3ZFyr/fgzLkiAfWtiUcDjT6EYB eK9YLsHnMl43AgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CG SAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMg aW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgB hvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQBMLFxAzMjwBy8etNxKb+o8DBz7A1N0aBtl ihy7tnYchYgL0CCd9OA+cniNDpyDoPLnaodkbOlYdep9jEeHlHAmaI7Co+Mxx4rRIjjCj85g Gq+9ZJBfzcHLj3wcZxsJ8qSLBH/63LjgIkhKlMUeShy8hx+Nk5O98uXTfD19w1i8SzCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEEEluySOQ8FZ1DvT9ZbjQKMwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMTEwMDQxNjQ3MzVaMCMGCSqGSIb3DQEJ BDEWBBS8hdKl+YrgjpiZzFMpnRmKuX54yDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgEL2U/phXnLESzBpLlTsayPFGDxjpsLLD48gpTdjnGa2VxlH z+ooYDMo8d2zJSazGPeQQDFqeYXrPqGD/GceZTelcotkA5mfero5Do939EHD8f+Ka6lgzKI2 9P/XqgAgkhWQkjpYat3QorxW9bEEPZbQNSongRA8+kzgUwfVF4pg --------------msBFEF04EFCA88A75D20F17558-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f948qeK29163 for ietf-smime-bks; Thu, 4 Oct 2001 01:52:40 -0700 (PDT) Received: from femail36.sdc1.sfba.home.com (femail36.sdc1.sfba.home.com [24.254.60.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f948qdD29155 for <ietf-smime@imc.org>; Thu, 4 Oct 2001 01:52:39 -0700 (PDT) Received: from revelation ([65.4.166.11]) by femail36.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20011004085234.FZOC2107.femail36.sdc1.sfba.home.com@revelation>; Thu, 4 Oct 2001 01:52:34 -0700 Reply-To: <jimsch@exmsft.com> From: "Jim Schaad" <jimsch@nwlink.com> To: "'Housley, Russ'" <rhousley@rsasecurity.com> Cc: <ietf-smime@imc.org> Subject: RE: draft-ietf-smime-rfc2630bis-05.txt and draft-ietf-smime-cmsalg-06.txt Date: Thu, 4 Oct 2001 01:52:52 -0700 Message-ID: <004a01c14cb1$f426cb30$0c00a8c0@soaringhawk.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <5.0.1.4.2.20011003162916.02e31260@exna07.securitydynamics.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> The current version does not have the requested change by me to reference the IETF ASN.1 modules for items such as certificate. I thought that you had agreed to do this. Do I remember incorrectly or did you change your mind? Jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Housley, Russ > Sent: Wednesday, October 03, 2001 1:35 PM > To: jis@mit.edu; mleech@nortelnetworks.com > Cc: scoya@ietf.org; ietf-smime@imc.org > Subject: draft-ietf-smime-rfc2630bis-05.txt and > draft-ietf-smime-cmsalg-06.txt > > > > Jeff & Marcus: > > The S/MIME WG is finished with rfc2630bis-05 and cmsalg-06. These > documents are ready for publication as standards-track RFCs > following IETF > Last Call and IESG approval. The rfc2630bis-05 document > obsoletes RFC 2630. > > Title : Cryptographic Message Syntax > Author(s) : R. Housley > Filename : draft-ietf-smime-rfc2630bis-05.txt > Pages : 52 > Date : 01-Oct-01 > > Title : Cryptographic Message Syntax (CMS) Algorithms > Author(s) : R. Housley > Filename : draft-ietf-smime-cmsalg-06.txt > Pages : 23 > Date : 01-Oct-01 > > Russ > Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f93Ka3222065 for ietf-smime-bks; Wed, 3 Oct 2001 13:36:03 -0700 (PDT) Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f93Ka1D22061 for <ietf-smime@imc.org>; Wed, 3 Oct 2001 13:36:01 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 3 Oct 2001 20:32:57 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA26521; Wed, 3 Oct 2001 16:35:59 -0400 (EDT) Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id QAA23757; Wed, 3 Oct 2001 16:35:57 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQTT4H>; Wed, 3 Oct 2001 16:35:56 -0400 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.14]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQTT4F; Wed, 3 Oct 2001 16:35:49 -0400 From: "Housley, Russ" <rhousley@rsasecurity.com> To: jis@mit.edu, mleech@nortelnetworks.com Cc: scoya@ietf.org, ietf-smime@imc.org Message-Id: <5.0.1.4.2.20011003162916.02e31260@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Wed, 03 Oct 2001 16:34:39 -0400 Subject: draft-ietf-smime-rfc2630bis-05.txt and draft-ietf-smime-cmsalg-06.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Jeff & Marcus: The S/MIME WG is finished with rfc2630bis-05 and cmsalg-06. These documents are ready for publication as standards-track RFCs following IETF Last Call and IESG approval. The rfc2630bis-05 document obsoletes RFC 2630. Title : Cryptographic Message Syntax Author(s) : R. Housley Filename : draft-ietf-smime-rfc2630bis-05.txt Pages : 52 Date : 01-Oct-01 Title : Cryptographic Message Syntax (CMS) Algorithms Author(s) : R. Housley Filename : draft-ietf-smime-cmsalg-06.txt Pages : 23 Date : 01-Oct-01 Russ Received: by above.proper.com (8.11.6/8.11.3) id f92B4b716710 for ietf-smime-bks; Tue, 2 Oct 2001 04:04:37 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f92B4aD16705 for <ietf-smime@imc.org>; Tue, 2 Oct 2001 04:04:36 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03564; Tue, 2 Oct 2001 07:04:33 -0400 (EDT) Message-Id: <200110021104.HAA03564@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-sender-auth-00.txt Date: Tue, 02 Oct 2001 07:04:33 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> --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 : Sender Authentication and the Surreptitious Forwarding Attack in CMS and S/MIME Author(s) : D. Davis Filename : draft-ietf-smime-sender-auth-00.txt Pages : Date : 01-Oct-01 By default, a CMS signed-and-encrypted document or message authenticates only the document's originator, and not the person who encrypted the document. This subtle limitation exposes CMS and S/MIME signed-and-encrypted data to 'surreptitious forwarding.' Secure-messaging standards have treated surreptitious forwarding as an insoluble problem of user carelessness, and have long accepted the risk of this attack. This document discusses easy cryptographic remedies for this attack, suitable for incorporation into the CMS and S/MIME specifications. This document is an abridgement of [U2001]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-sender-auth-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-sender-auth-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-sender-auth-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011001113015.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-sender-auth-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-sender-auth-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011001113015.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by above.proper.com (8.11.6/8.11.3) id f92B4V216702 for ietf-smime-bks; Tue, 2 Oct 2001 04:04:31 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f92B4TD16698 for <ietf-smime@imc.org>; Tue, 2 Oct 2001 04:04:30 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03535; Tue, 2 Oct 2001 07:04:27 -0400 (EDT) Message-Id: <200110021104.HAA03535@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-cmsalg-06.txt Date: Tue, 02 Oct 2001 07:04:26 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> --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 : Cryptographic Message Syntax (CMS) Algorithms Author(s) : R. Housley Filename : draft-ietf-smime-cmsalg-06.txt Pages : 23 Date : 01-Oct-01 This document describes several cryptographic algorithms for use with the Cryptographic Message Syntax (CMS) [CMS]. CMS is used to digitally sign, digest, authenticate, or encrypt arbitrary messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-cmsalg-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-cmsalg-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-cmsalg-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011001113006.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-cmsalg-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-cmsalg-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011001113006.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f92B4Qt16696 for ietf-smime-bks; Tue, 2 Oct 2001 04:04:26 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f92B4PD16692 for <ietf-smime@imc.org>; Tue, 2 Oct 2001 04:04:25 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03519; Tue, 2 Oct 2001 07:04:22 -0400 (EDT) Message-Id: <200110021104.HAA03519@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-rfc2630bis-05.txt Date: Tue, 02 Oct 2001 07:04:21 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> --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 : Cryptographic Message Syntax Author(s) : R. Housley Filename : draft-ietf-smime-rfc2630bis-05.txt Pages : 52 Date : 01-Oct-01 This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2630bis-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-rfc2630bis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-rfc2630bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011001112957.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-rfc2630bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-rfc2630bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011001112957.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f928WVl04327 for ietf-smime-bks; Tue, 2 Oct 2001 01:32:31 -0700 (PDT) Received: from femail37.sdc1.sfba.home.com (femail37.sdc1.sfba.home.com [24.254.60.31]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f928WTD04323 for <ietf-smime@imc.org>; Tue, 2 Oct 2001 01:32:29 -0700 (PDT) Received: from revelation ([65.4.166.11]) by femail37.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20011002083225.JVAI10339.femail37.sdc1.sfba.home.com@revelation>; Tue, 2 Oct 2001 01:32:25 -0700 Reply-To: <jimsch@exmsft.com> From: "Jim Schaad" <jimsch@nwlink.com> To: "'Pawling, John'" <John.Pawling@GetronicsGov.com>, "'Housley, Russ'" <rhousley@rsasecurity.com> Cc: <ietf-smime@imc.org> Subject: RE: Comments on draft-ietf-smime-rfc2630bis-03 Date: Tue, 2 Oct 2001 01:32:47 -0700 Message-ID: <002201c14b1c$d0df30e0$0c00a8c0@soaringhawk.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <0B95FB5619B3D411817E006008A59259B51BC2@wfhqex06.gfgsi.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> John, I re-examined this and I agree that you are correct and that the language in the updated draft is correct. Interestingly, I now understand the reason that all new content infos are required to NOT start with a CHOICE. Specifically the tag representing the choice is not covered by the signature and thus is open to changing under the PKCS#7 rules (but not under the updated CMS rules). I don't know that there are any advantages to removing the requirement from the updated CMS draft, but it is certainly no longer needed as the byte is now covered by the signature (and is one less odd ball statement to have around). jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Pawling, John > Sent: Wednesday, September 19, 2001 1:44 PM > To: 'jimsch@exmsft.com'; 'Housley, Russ' > Cc: ietf-smime@imc.org > Subject: RE: Comments on draft-ietf-smime-rfc2630bis-03 > > > > Jim, > > > However, if an > > RFC 2634 signed receipt is encapsulated in the PKCS #7 > signedData > > type, then the Receipt SEQUENCE is DER encoded [X.509-88] in the > > SignedData contentInfo content ANY field (a SEQUENCE, > not an OCTET > > STRING). Therefore, the message digest is computed > using only the > > value octets of the Receipt SEQUENCE encoding. > > [Jim wrote: I have a minor issue with the last sentence. The > digest must > include > the type and length bytes of the SEQUENCE and I don't believe > that this > is correctly stated in the text. Suggest: "Therefore, the message > digest is computed using the entirety of the Receipt SEQUENCE > encoding."] > > I agree that when an RFC 2634 [ESS] signed receipt is > encapsulated in the > CMS signedData type, then the message digest is computed > using the entire > Receipt SEQUENCE encoding (as specified in RFC 2634 and RFC > 2630). However, > when a signed receipt is encapsulated in the PKCS #7 > signedData type, then > RFC 2315 (PKCS #7), Section 9.3 (see below) specifies that the message > digest is computed using only the value octets (not the > identifier octets or > the length octets) of the "content being signed" (i.e. > Receipt SEQUENCE > encoding). > > When we performed signed receipt interoperability testing > between the S/MIME > Freeware Library (SFL) and Microsoft, the Microsoft implementation was > initially encapsulating the signed receipt in a PKCS #7 > signedData type. > When creating a PKCS #7 signed receipt, the Microsoft > implementation encoded > the Receipt SEQUENCE in the SignedData contentInfo content > ANY field (a > SEQUENCE, not an OCTET STRING) and calculated the message > digest using only > the value octets of the Receipt SEQUENCE encoding. Once we > modified the SFL > to accept this format, then we were able to decode and verify > the Microsoft > PKCS #7 signed receipt. Please note that Microsoft later generated a > >>CMS<< signed receipt that we were able to decode and verify > using the SFL > without any special modifications. > > RFC 2315 (PKCS #7), Section 9.3: > > "9.3 Message-digesting process > > The message-digesting process computes a message digest on > either the > content being signed or the content together with the signer's > authenticated attributes. In either case, the initial input to the > message-digesting process is the "value" of the content > being signed. > Specifically, the initial input is the contents octets of the DER > encoding of the content field of the ContentInfo value to which the > signing process is applied. Only the contents octets of the DER > encoding of that field are digested, not the identifier > octets or the > length octets." > > =========================================== > John Pawling, John.Pawling@GetronicsGov.com > Getronics Government Solutions, LLC > =========================================== > Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f91KCvU16676 for ietf-smime-bks; Mon, 1 Oct 2001 13:12:57 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f91KCuD16671 for <ietf-smime@imc.org>; Mon, 1 Oct 2001 13:12:56 -0700 (PDT) Received: from jet.isi.edu (jet.isi.edu [128.9.160.87]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f91KCwv26583; Mon, 1 Oct 2001 13:12:58 -0700 (PDT) From: RFC Editor <rfc-ed@ISI.EDU> Received: (from rfc-ed@localhost) by jet.isi.edu (8.8.7/8.8.6) id NAA16768; Mon, 1 Oct 2001 13:12:58 -0700 (PDT) Date: Mon, 1 Oct 2001 13:12:58 -0700 (PDT) Message-Id: <200110012012.NAA16768@jet.isi.edu> To: t.dean@eris.dera.gov.uk, w.ottaway@eris.dera.gov.uk Subject: authors 48 hours: RFC 3183 <draft-ietf-smime-domsec-09.txt> NOW AVAILABLE Cc: rfc-ed@ISI.EDU, ietf-smime@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> ****IMPORTANT***** Updated 2001/10/01 RFC AUTHOR(S): -------------- This is your LAST CHANCE to make changes to your RFC to be: draft-ietf-smime-domsec-09.txt, once the document is published we *WILL NOT* make any changes. Please check your document at ftp://ftp.rfc-editor.org/in-notes/authors/rfc2183.txt You have 48 hours (2 WORK days) to look over your document for any last minute editorial nits, *especially check your code.* If the main editor of your document is out of town, or if you are going out of town you may request an extension. Extensions are granted at the prerogative of the RFC Editor. ** Please send us a list of suitable keywords for this document, over and above those which appear in the title. Frequently INCORRECT information includes - Contact Information - References (are they up to date) - Section Numbers (especially if you originally put the copyright somewhere other than the VERY end of the document, or if you numbered the "Status of the Memo" field) Please send us the changes, *DO NOT* send a new document with the changes made. (If we think that the changes might be more than editorial we will contact the AD or the IESG to confirm that the changes do not require review.) Send us the changes in THIS format. 1)*** SECTION #'s*** [i.e. Section 5, 2nd paragraph] 2) the text you want changed, 3) the new correct text and 4) if the changes are spacing or indentation than please note that. FOR EXAMPLE: Section 5.6, 3rd paragraph OLD: The quick brown fox jumped over the lazy dog. NEW: The quick brown dog jumps over the lazy fox. ^^^ ^ ^^^ If you have a whole paragraph to replace you do not need to use the arrow to point out the differences INTRODUCTION, 2nd paragraph Replace OLD: alsdfja;sldjf;lajsd;fljas;dlfj; With NEW: nv;alkjd;lsf;aoisj;ltjka;sldkjf Spacing or indentation problems... Section 10, 1st paragraph (remove spaces between bit and of, add space after butter) OLD: Better botter bought a bit of bitter butterMary mary quite contrary NEW: Better botter bought a bit of bitter butter Mary mary quite contrary If we do not hear from you within 48 hours of this email, the document will be published to the community at large AS IS. Thanks for your cooperation, -RFC Editor ==================================================================== A new Request for Comments is now available from ftp.isi.edu. As the contact for a primary RFC library, you are responsible for retrieving this RFC from ISI and installing it in your RFC library. The official RFC announcement will be sent to the public distribution list in one working day from this posting. RFC 3183 Title: Domain Security Services using S/MIME Author(s): T. Dean, W. Ottaway Status: Experimental Date: October 2001 Mailbox: t.dean@eris.dera.gov.uk, w.ottaway@eris.dera.gov.uk Pages: 24 Characters: 57330 SeeAlso/Updates/Obsoletes: None I-D Tag: draft-ietf-smime-domsec-09.txt pathname: ftp://ftp.rfc-editor.org/in-notes/rfc3183.txt ====================================================================== Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f91Ax1X08248 for ietf-smime-bks; Mon, 1 Oct 2001 03:59:01 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f91AwxD08244 for <ietf-smime@imc.org>; Mon, 1 Oct 2001 03:59:00 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10682; Mon, 1 Oct 2001 06:58:54 -0400 (EDT) Message-Id: <200110011058.GAA10682@ietf.org> To: IETF-Announce: ; Cc: RFC Editor <rfc-editor@isi.edu> Cc: Internet Architecture Board <iab@isi.edu> Cc: ietf-smime@imc.org From: The IESG <iesg-secretary@ietf.org> Subject: Protocol Action: Reuse of CMS Content Encryption Keys to Proposed Standard Date: Mon, 01 Oct 2001 06:58:54 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-ID: <ietf-smime.imc.org> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> The IESG has approved the Internet-Draft 'Reuse of CMS Content Encryption Keys' <draft-ietf-smime-rcek-04.txt> as a Proposed Standard. This document is the product of the S/MIME Mail Security Working Group. The IESG contact persons are Jeffrey Schiller and Marcus Leech. Technical Summary SMIME's Cryptographic Message Syntax (CMS) provides a way to use public key cryptography to encrypt a symmetric key which in turn is used to encrypt the content of the message. There are applications where two parties may need to exchange multiple messages and wish to avoid the overhead of the public key operation (public key cryptography is much more computationally expensive then symmetric algorithms). This document defines a secure way of labeling the symmetric key (called the Content Encryption Key or CEK) in a message such that it may be used as a Key Encrypting Key (KEK) for a later message. This technique is not advisable for just any application and the document explains where it makes sense and where it doesn't. Working Group Summary The S/MIME Working Group came to consensus on this document. Protocol Quality This protocol was reviewed for the IESG by Jeffrey I. Schiller.