Document Action: Preventing the Million Message Attack on CMS to Informational

[The IESG <[e-mail]>]

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 <[e-mail]>; 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: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>, Internet Architecture Board <[e-mail]>, [e-mail]
From: The IESG <[e-mail]>
Subject: Document Action: Preventing the Million Message Attack on CMS to Informational
Date: Mon, 29 Oct 2001 16:26:44 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>; 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: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>, Internet Architecture Board <[e-mail]>, [e-mail]
From: The IESG <[e-mail]>
Subject: Document Action: Triple-DES and RC2 Key Wrapping to Informational
Date: Mon, 29 Oct 2001 15:55:55 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>; 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: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>, Internet Architecture Board <[e-mail]>, [e-mail]
From: The IESG <[e-mail]>
Subject: Protocol Action: Password-based Encryption for S/MIME to Proposed Standard
Date: Mon, 29 Oct 2001 12:25:27 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>; 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" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>; 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: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, Peter Sylvester <[e-mail]>
Cc: [e-mail]
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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.
[e-mail]
781 245 6996 x227


> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Friday, October 26, 2001 2:21 PM
> To: Peter Sylvester
> Cc: [e-mail]
> 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:[phone] x227
EMAIL;PREF;INTERNET:[e-mail]
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 <[e-mail]>; 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 <[e-mail]>; 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 <[e-mail]>; 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" <[e-mail]>
To: Peter Sylvester <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
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: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>; 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 <[e-mail]>
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: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: sender-auth and ira
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>; 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 <[e-mail]>; 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 <[e-mail]>; 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" <[e-mail]>
To: Peter Sylvester <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
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: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>; Thu, 25 Oct 2001 20:58:48 -0700 (PDT)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [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 [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <100406872106482>; Fri, 26 Oct 2001 16:58:41 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: sender-auth and ira
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Fri, 26 Oct 2001 16:58:41 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Jim Schaad" <[e-mail]> 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 <[e-mail]>; 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: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, <[e-mail]>
Subject: RE: sender-auth and ira
Date: Thu, 25 Oct 2001 19:30:57 -0700
Message-ID: <001001c15dc6$3eb82d90$[e-mail]>
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: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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
"[e-mail]", my mailbox name was
"[e-mail]".  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 "[e-mail]",
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: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Housley, Russ
> Sent: Thursday, October 25, 2001 7:05 AM
> To: [e-mail]
> 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: [e-mail]
Message-Id: <p0510033ab7fe415ac0dd@[165.227.249.20]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 25 Oct 2001 15:25:24 -0700
To: "Daniel Brown" <[e-mail]>, "Housley, Russ" <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: sender-auth and ira
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>; 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" <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: [e-mail]
Message-ID: <[e-mail]>
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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: [e-mail]
Message-Id: <p0510032bb7fde9fe3a58@[165.227.249.20]>
In-Reply-To:  <[e-mail]>
References: <[e-mail]>
Date: Thu, 25 Oct 2001 09:36:11 -0700
To: "Housley, Russ" <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: sender-auth and ira
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>; 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 <[e-mail]>
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: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: sender-auth and ira
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>; 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 <[e-mail]>; 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 <[e-mail]>; 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: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 25 Oct 2001 10:04:56 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: sender-auth and ira
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>; 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" <[e-mail]>
To: "Musy Michel-P28089" <[e-mail]>
Cc: "Housley, Russ" <[e-mail]>, <[e-mail]>
Subject: RE: WG Last Call: x400transport and x400wrap
Date: Tue, 23 Oct 2001 15:52:56 -0400
MIME-Version: 1.0
Message-ID: <[e-mail]>
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: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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: [phone]  |
 |  Principal Engineer                  Fax: [phone]  |
 -----------------------------------------------------------



-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Musy Michel-P28089
Sent: Monday, October 22, 2001 13:27
To: Housley, Russ; [e-mail]
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: [e-mail]

------------------- 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:[e-mail]]
Sent: Monday, October 22, 2001 7:21 AM
To: [e-mail]
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 <[e-mail]>; 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" <[e-mail]>
To: [e-mail]
cc: [e-mail]
Message-ID: <[e-mail]>
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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" <[e-mail]> on 10/07/2001 08:56:58 PM

Please respond to [e-mail]

To:   [e-mail]
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 <[e-mail]>; 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 <[e-mail]>; 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 <[e-mail]>; 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: <[e-mail]>
From: Musy Michel-P28089 <[e-mail]>
To: "Housley, Russ" <[e-mail]>, [e-mail]
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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: [e-mail]

------------------- 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:[e-mail]]
Sent: Monday, October 22, 2001 7:21 AM
To: [e-mail]
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 <[e-mail]>; 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 <[e-mail]>; 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: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 22 Oct 2001 10:20:49 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: WG Last Call: x400transport and x400wrap
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>; 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: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-x400transport-04.txt
Date: Mon, 22 Oct 2001 07:04:16 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--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 <[e-mail]>; 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: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-password-06.txt
Date: Mon, 22 Oct 2001 07:04:05 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--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 <[e-mail]>; 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: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3183 on Domain Security Services using S/MIME
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 19 Oct 2001 15:59:55 -0700
From: RFC Editor <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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:    [e-mail],
                    [e-mail] 
        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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  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="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

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: <[e-mail]>

--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 <[e-mail]>; 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: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3185 on Reuse of CMS Content Encryption Keys
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 19 Oct 2001 15:56:46 -0700
From: RFC Editor <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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:    [e-mail], [e-mail]
        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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  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="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

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: <[e-mail]>

--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 <[e-mail]>; 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: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3126 on Electronic Signature Formats
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 19 Oct 2001 15:51:23 -0700
From: RFC Editor <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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:    [e-mail], Denis.Pinkas @bull.net,
                    [e-mail], [e-mail]
        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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  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="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

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: <[e-mail]>

--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 <[e-mail]>; 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: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3125 on Electronic Signature Policies
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 19 Oct 2001 15:50:23 -0700
From: RFC Editor <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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:    [e-mail], [e-mail],
                    [e-mail] 
        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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  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="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

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: <[e-mail]>

--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 <[e-mail]>; 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: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3183 on Domain Security Services using S/MIME
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: RFC Editor <[e-mail]>
Date: Wed, 17 Oct 2001 14:48:21 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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:    [e-mail],
                    [e-mail] 
        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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  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="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

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: <[e-mail]>

--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 <[e-mail]>; 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: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3126 on Electronic Signature Formats
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: RFC Editor <[e-mail]>
Date: Wed, 17 Oct 2001 14:47:53 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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:    [e-mail], Denis.Pinkas @bull.net,
                    [e-mail], [e-mail]
        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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  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="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

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: <[e-mail]>

--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 <[e-mail]>; 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: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3125 on Electronic Signature Policies
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: RFC Editor <[e-mail]>
Date: Wed, 17 Oct 2001 14:47:48 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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:    [e-mail], [e-mail],
                    [e-mail] 
        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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  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="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

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: <[e-mail]>

--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 <[e-mail]>; 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: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3185 on Reuse of CMS Content Encryption Keys
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 16 Oct 2001 13:46:22 -0700
From: RFC Editor <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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:    [e-mail], [e-mail]
        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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  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="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

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: <[e-mail]>

--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 <[e-mail]>; 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: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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, [e-mail]
Getronics Government Solutions, LLC
===========================================


-----Original Message-----
From: Magnus Nystrom [mailto:[e-mail]]
Sent: Friday, October 12, 2001 5:23 AM
To: [e-mail]
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 <[e-mail]>; 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: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3183 on Domain Security Services using S/MIME
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 12 Oct 2001 16:26:33 -0700
From: RFC Editor <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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:    [e-mail],
                    [e-mail] 
        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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  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="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

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: <[e-mail]>

--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 <[e-mail]>; 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" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
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: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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: [phone]
>  Malvern Technology Centre,   Fax: [phone]
>  St. Andrews Road,            email: [e-mail]
>  Malvern,
>  Worcs,
>  WR14 3PS
>
>  All opinions are my own.
>
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Blake Ramsdell
> > Sent: 04 October 2001 21:00
> > To: 'William Ottaway'; [e-mail]
> > 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:[e-mail]]
> > Sent: Friday, September 21, 2001 6:42 AM
> > To: [e-mail]
> > 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: [phone]
> >  Malvern Technology Centre,   Fax: [phone]
> >  St. Andrews Road,            email: [e-mail]
> >  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 <[e-mail]>; 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" <[e-mail]>
To: "Blake Ramsdell" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: DOMSEC and S/MIME Gateway Protocol comparison
Date: Fri, 12 Oct 2001 15:36:28 +0100
Message-ID: <[e-mail]>
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: <[e-mail]>
X-Virus-Scanned: by internal AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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: [phone]
 Malvern Technology Centre,   Fax: [phone]
 St. Andrews Road,            email: [e-mail]
 Malvern,
 Worcs,
 WR14 3PS

 All opinions are my own.


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Blake Ramsdell
> Sent: 04 October 2001 21:00
> To: 'William Ottaway'; [e-mail]
> 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:[e-mail]]
> Sent: Friday, September 21, 2001 6:42 AM
> To: [e-mail]
> 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: [phone]
>  Malvern Technology Centre,   Fax: [phone]
>  St. Andrews Road,            email: [e-mail]
>  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 <[e-mail]>; 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 <[e-mail]>; 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 <[e-mail]>; 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 <[e-mail]>
To: <[e-mail]>
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: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>; 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 <[e-mail]>; 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 <[e-mail]>; 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" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>; 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: [e-mail]
To: [e-mail]
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: [e-mail]
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Message-Id: <200110111726109.SM00259@tw-web2>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>; 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" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>; 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 <[e-mail]>; 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 <[e-mail]>; 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" <[e-mail]>
To: "Nystrom, Magnus" <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>; 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 <[e-mail]>; 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 <[e-mail]>; 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 <[e-mail]>
Reply-To: =?iso-8859-1?Q?Magnus_Nystr=F6m?= <[e-mail]>
To: <[e-mail]>
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: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>; 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 <[e-mail]>; 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 <[e-mail]>; 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 <[e-mail]>
Reply-To: =?iso-8859-1?Q?Magnus_Nystr=F6m?= <[e-mail]>
To: <[e-mail]>
Subject: RE: WG Last Call: cmsalg
Message-ID: <Pine.WNT.4.31.0110111105180.1168-100000@mnystrom-lap>
X-X-Sender: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>; 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: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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, [e-mail]
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 <[e-mail]>; 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 [e-mail])
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 [e-mail])
Date: Tue, 9 Oct 2001 16:55:40 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  Encryption Cert OID
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Eric Norman <[e-mail]> 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 <[e-mail]>; 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 [e-mail]; Mon, 08 Oct 2001 21:04:36 -0500
Date: Mon, 8 Oct 2001 21:04:36 -0500 (CDT)
From: Eric Norman <[e-mail]>
To: SMIME list <[e-mail]>
Subject: Encryption Cert OID
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Paul Hoffman / IMC'" <[e-mail]>, "'Housley, Russ'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: WG Last Call: cmsalg
Date: Mon, 8 Oct 2001 17:37:48 -0700
Message-ID: <006a01c1505a$9f523c50$[e-mail]>
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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:[e-mail]] 
> Sent: Monday, October 08, 2001 4:57 PM
> To: Housley, Russ; [e-mail]
> Cc: [e-mail]
> 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: [e-mail]
Message-Id: <p0510030db7e7ed7ef568@[165.227.249.20]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]> <[e-mail]>
Date: Mon, 8 Oct 2001 16:57:26 -0700
To: "Housley, Russ" <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: WG Last Call: cmsalg
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>; 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 <[e-mail]>; 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 <[e-mail]>; 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" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
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$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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:[e-mail]]
> > Sent: Monday, October 08, 2001 10:50 AM
> > To: [e-mail]
> > Cc: [e-mail]
> > 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 <[e-mail]>; 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: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: WG Last Call: cmsalg
Date: Mon, 8 Oct 2001 11:56:07 -0700
Message-ID: <006401c1502a$e3db8eb0$[e-mail]>
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: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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:[e-mail]] 
> Sent: Monday, October 08, 2001 10:50 AM
> To: [e-mail]
> Cc: [e-mail]
> 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 <[e-mail]>; 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 <[e-mail]>; 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 <[e-mail]>; 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" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
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$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>; 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 <[e-mail]>; Mon, 8 Oct 2001 23:21:20 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id XAA324661 for [e-mail]; Mon, 8 Oct 2001 23:21:19 +1300 (NZDT) (sender [e-mail])
Date: Mon, 8 Oct 2001 23:21:19 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: RE: Questions on AuthenticatedData
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>; 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 [e-mail])
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 [e-mail])
Date: Mon, 8 Oct 2001 18:23:37 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Questions on AuthenticatedData
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Jim Schaad" <[e-mail]> 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 <[e-mail]>; 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: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Peter Gutmann'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Questions on AuthenticatedData
Date: Sun, 7 Oct 2001 22:01:07 -0700
Message-ID: <006001c14fb6$3db133b0$[e-mail]>
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: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Peter Gutmann
> Sent: Sunday, October 07, 2001 6:45 PM
> To: [e-mail]; [e-mail]
> Subject: Re: Questions on AuthenticatedData
> 
> 
> 
> "Jim Schaad" <[e-mail]> 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 <[e-mail]>; 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 [e-mail])
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 [e-mail])
Date: Mon, 8 Oct 2001 14:45:15 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  Questions on AuthenticatedData
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Jim Schaad" <[e-mail]> 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 <[e-mail]>; 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 <[e-mail]>; Sun, 7 Oct 2001 17:56:53 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>
Subject: Questions on AuthenticatedData
Date: Sun, 7 Oct 2001 17:56:58 -0700
Message-ID: <005f01c14f94$22361b90$[e-mail]>
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>; 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: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'James M Galvin '" <[e-mail]>, "'Housley, Russ '" <[e-mail]>
cc: "''[e-mail]' '" <[e-mail]>
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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: '[e-mail]'
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 <[e-mail]>


On Fri, 5 Oct 2001, Housley, Russ wrote:

    Date: Fri, 05 Oct 2001 16:51:09 -0400
    From: "Housley, Russ" <[e-mail]>
    To: Blake Ramsdell <[e-mail]>
    Cc: "'[e-mail]'" <[e-mail]>
    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 [phone] x103  Fax [phone]
    





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 <[e-mail]>; 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 <[e-mail]> for [e-mail]; Sat, 06 Oct 2001 10:34:52 -0400 (EDT)
Date: Sat, 06 Oct 2001 10:37:07 -0400 (EDT)
From: James M Galvin <[e-mail]>
Subject: Re: multipart/signed clarifications
In-reply-to: <[e-mail]>
X-Sender: [e-mail]
To: "Housley, Russ" <[e-mail]>, Blake Ramsdell <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>


On Fri, 5 Oct 2001, Housley, Russ wrote:

    Date: Fri, 05 Oct 2001 16:51:09 -0400
    From: "Housley, Russ" <[e-mail]>
    To: Blake Ramsdell <[e-mail]>
    Cc: "'[e-mail]'" <[e-mail]>
    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 [phone] x103  Fax [phone]
    



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 <[e-mail]>; 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: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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:[e-mail]]
Sent: Friday, October 05, 2001 1:51 PM
To: Blake Ramsdell
Cc: '[e-mail]'
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 [phone] x103  Fax [phone]



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 <[e-mail]>; 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 <[e-mail]>; 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 <[e-mail]>; 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" <[e-mail]>
To: Blake Ramsdell <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
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: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 [phone] x103  Fax [phone]


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 <[e-mail]>; 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: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 [phone] x103  Fax [phone]




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 <[e-mail]>; 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: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'William Ottaway'" <[e-mail]>, [e-mail]
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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:[e-mail]]
Sent: Friday, September 21, 2001 6:42 AM
To: [e-mail]
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: [phone]
 Malvern Technology Centre,   Fax: [phone]
 St. Andrews Road,            email: [e-mail]
 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 <[e-mail]>; 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 <[e-mail]>; Fri, 5 Oct 2001 01:33:52 +0900
Message-ID: <[e-mail]>
Date: Fri, 05 Oct 2001 01:47:35 +0900
From: "Chung, KwonSung" <[e-mail]>
Organization: (C)BCQRE
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: mime parser
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msBFEF04EFCA88A75D20F17558"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>; 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: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>
Cc: <[e-mail]>
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$[e-mail]>
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: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Housley, Russ
> Sent: Wednesday, October 03, 2001 1:35 PM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]
> 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 <[e-mail]>; 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" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>; 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: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-sender-auth-00.txt
Date: Tue, 02 Oct 2001 07:04:33 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--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 <[e-mail]>; 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: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-cmsalg-06.txt
Date: Tue, 02 Oct 2001 07:04:26 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--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 <[e-mail]>; 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: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-rfc2630bis-05.txt
Date: Tue, 02 Oct 2001 07:04:21 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--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 <[e-mail]>; 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: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Pawling, John'" <[e-mail]>, "'Housley, Russ'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Comments on draft-ietf-smime-rfc2630bis-03
Date: Tue, 2 Oct 2001 01:32:47 -0700
Message-ID: <002201c14b1c$d0df30e0$[e-mail]>
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: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Pawling, John
> Sent: Wednesday, September 19, 2001 1:44 PM
> To: '[e-mail]'; 'Housley, Russ'
> Cc: [e-mail]
> 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, [e-mail]
> 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 <[e-mail]>; 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 <[e-mail]>
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: <[e-mail]>
To: [e-mail], [e-mail]
Subject: authors 48 hours: RFC 3183 <draft-ietf-smime-domsec-09.txt> NOW AVAILABLE
Cc: [e-mail], [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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:    [e-mail],
                    [e-mail] 
        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 <[e-mail]>; 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: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>
Cc: [e-mail]
From: The IESG <[e-mail]>
Subject: Protocol Action: Reuse of CMS Content Encryption Keys to Proposed Standard
Date: Mon, 01 Oct 2001 06:58:54 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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.