SignedReceipt

["Dieter Bratko" <[e-mail]>]

Hello,

Implementing the ESS Signed Receipt service I would like to tell the
following question regarding the role of the message originator:
According to RFC2634 the signedContentIdentifier field should contain
user-specific identification information (such as a user name or public
keying material identification information). When creating a receipt the
signedContentIdentifier is copied from the receiptRequest to the receipt:

Receipt ::= SEQUENCE {
  version ESSVersion,
  contentType ContentType,
  signedContentIdentifier ContentIdentifier,
  originatorSignatureValue OCTET STRING }



Is my interpretation right that the user-specific identification information
implicitly contained in the signedContentIdentifier -- since it has to be
the same for any receiptRequest attribute of any SignerInfo containing a
receiptRequest attribute -- refers to the (one and only) message originator
(sender), but the originatorSignatureValue field holds the signature value
from the SignerInfo just processed (which not necessarily has to be the
signerInfo of the originator); and when creating the receipt it does not
mind which SignerInfo it is based on (the validator must be able to validate
receipts based on any SignerInfo contained in the original SignedData)?

Regards,
Dieter Bratko

---------
Dieter Bratko, <mailto:[e-mail]>
Institute for Applied Information Processing and Communications (IAIK)
Graz University of Technology, Inffeldgasse 16a, 8010 Graz, Austria,
http://jce.iaik.tugraz.at/




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gASF1km13404 for ietf-smime-bks; Thu, 28 Nov 2002 07:01:46 -0800 (PST)
Received: from mailrelay.tugraz.at (mailrelay.tu-graz.ac.at [129.27.3.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gASF1hg13398 for <[e-mail]>; Thu, 28 Nov 2002 07:01:44 -0800 (PST)
Received: from iaik.at (iaik.tu-graz.ac.at [129.27.152.30]) by mailrelay.tugraz.at (8.12.6/8.12.6) with ESMTP id gASF1fkR009797 for <[e-mail]>; Thu, 28 Nov 2002 16:01:41 +0100 (MET)
Received: from edison [129.27.152.88] by iaik.at (SMTPD32-7.07) id A01BF240026; Thu, 28 Nov 2002 16:02:51 +0100
Received: from 127.0.0.1 [127.0.0.1] by edison (IAIK S/MIME Mapper 2.01 18/May/2001); Do, 28 Nov 2002 16:02:51 +0100
Message-ID: <032e01c296ef$38b150d0$[e-mail]>
From: "Dieter Bratko" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: SignedReceipt
Date: Thu, 28 Nov 2002 16:02:50 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
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>

Hello,

Implementing the ESS Signed Receipt service I would like to tell the
following question regarding the role of the message originator:
According to RFC2634 the signedContentIdentifier field should contain
user-specific identification information (such as a user name or public
keying material identification information). When creating a receipt the
signedContentIdentifier is copied from the receiptRequest to the receipt:

Receipt ::= SEQUENCE {
  version ESSVersion,
  contentType ContentType,
  signedContentIdentifier ContentIdentifier,
  originatorSignatureValue OCTET STRING }



Is my interpretation right that the user-specific identification information
implicitly contained in the signedContentIdentifier -- since it has to be
the same for any receiptRequest attribute of any SignerInfo containing a
receiptRequest attribute -- refers to the (one and only) message originator
(sender), but the originatorSignatureValue field holds the signature value
from the SignerInfo just processed (which not necessarily has to be the
signerInfo of the originator); and when creating the receipt it does not
mind which SignerInfo it is based on (the validator must be able to validate
receipts based on any SignerInfo contained in the original SignedData)?

Regards,
Dieter Bratko

---------
Dieter Bratko, <mailto:[e-mail]>
Institute for Applied Information Processing and Communications (IAIK)
Graz University of Technology, Inffeldgasse 16a, 8010 Graz, Austria,
http://jce.iaik.tugraz.at/



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAQInvm16482 for ietf-smime-bks; Tue, 26 Nov 2002 10:49:57 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id gAQIntg16478 for <[e-mail]>; Tue, 26 Nov 2002 10:49:56 -0800 (PST)
Received: (qmail 7690 invoked from network); 26 Nov 2002 18:49:41 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.162.46) by woodstock.binhost.com with SMTP; 26 Nov 2002 18:49:41 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 26 Nov 2002 13:39:42 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: WG Last Call: draft-ietf-smime-aes-alg-05.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>

Dear S/MIME WG:

This message announces Working Group Last Call for the AES 
content-encryption algorithm document.

	Title		: Use of the AES Encryption Algorithm in CMS
	Author(s)	: J. Schaad
	Filename	: draft-ietf-smime-aes-alg-05.txt
	Pages		: 11
	Date		: 2002-11-21
	
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-aes-alg-05.txt

The intent is to publish the AES content-encryption algorithm document as a 
Standards Track RFC.

Please review this draft and post any comments to the [e-mail] 
mail list by Tuesday, 10 December 2002.  Unless traffic on the mail list 
indicates otherwise, I will send these to the IESG shortly after WG Last 
Call closes.

Russ




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAQInmH16476 for ietf-smime-bks; Tue, 26 Nov 2002 10:49:48 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id gAQInkg16472 for <[e-mail]>; Tue, 26 Nov 2002 10:49:46 -0800 (PST)
Received: (qmail 7697 invoked from network); 26 Nov 2002 18:49:42 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.162.46) by woodstock.binhost.com with SMTP; 26 Nov 2002 18:49:42 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 26 Nov 2002 13:48:58 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: WG Last Call: draft-ietf-smime-aes-alg-05.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>

I have a few editorial comments on the document, and I have one technical 
comment.

TECHNICAL

In section 2, in the paragraph on key agreement, why is DH-ES discussed, 
but not DH-SS?  I think that both should be accommodated.  The example 
section seems to accommodate both.

EDITORIAL

Please change "RSA #1" to "PKCS #1" throughout the document.

Please separate the references into to categories: Normative and Informative.

Please add the key wrap algorithm identifies to the ASN.1 module.

Russ



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAPDLgp04250 for ietf-smime-bks; Mon, 25 Nov 2002 05:21:42 -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 gAPDLeg04243 for <[e-mail]>; Mon, 25 Nov 2002 05:21:40 -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 IAA26449; Mon, 25 Nov 2002 08:18:57 -0500 (EST)
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-aes-alg-05.txt
Date: Mon, 25 Nov 2002 08:18:57 -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>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Use of the AES Encryption Algorithm in CMS
	Author(s)	: J. Schaad
	Filename	: draft-ietf-smime-aes-alg-05.txt
	Pages		: 11
	Date		: 2002-11-21
	
This document specifies the conventions for using the Advanced 
Encryption Standard (AES) algorithm [AES] for encryption with the 
Cryptographic Message Syntax (CMS) [CMS].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-aes-alg-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-aes-alg-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-aes-alg-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-aes-alg-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-aes-alg-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 majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAKJPM404113 for ietf-smime-bks; Wed, 20 Nov 2002 11:25:22 -0800 (PST)
Received: from srv0.ops.ietf.org (srv0.ietf55.ops.ietf.org [205.238.48.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAKJPKg04106 for <[e-mail]>; Wed, 20 Nov 2002 11:25:20 -0800 (PST)
Received: from [204.42.72.58] (helo=revelation) by srv0.ops.ietf.org with esmtp (Exim 4.10) id 18EaTR-000Hwf-00; Wed, 20 Nov 2002 19:25:21 +0000
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>, "'Blake Ramsdell'" <[e-mail]>
Subject: Comments on draft-ietf-smime-rfc2633bis-02.txt
Date: Wed, 20 Nov 2002 14:24:23 -0500
Message-ID: <000c01c290ca$85898150$[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.2800.1106
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>

1.  Section 3.6, para 1:  I don't' think it is correct to say that
compression "secures" anything.

2.  Section 36, para Last:  This text needs to be expanded beyond what
is there.  Minimum text should address:
	1.  don't compress a binary encryption.  (compressing a base64
of an encryption would yield benefits.)
	2.  Compress before sign if using a lossy algorithm.

	I might think of other things with some more thought.

3.  ASN.1 Module:  Need to get a new module ID from Russ before
continuing into last call.

4.  Need to finish TBDs before progressing into last call.

5.  I think we should define SMIMECapaiblity2 in this draft to deal with
the question of different combinations that are/are-not allowed for a
given set of transport/agreement/content encryptoin algorithms.  If this
is agreed to I will attempt to write some text in the next couple of
weeks.

Jim




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAKJ4La02444 for ietf-smime-bks; Wed, 20 Nov 2002 11:04:21 -0800 (PST)
Received: from srv0.ops.ietf.org (srv0.ietf55.ops.ietf.org [205.238.48.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAKJ4Ig02440 for <[e-mail]>; Wed, 20 Nov 2002 11:04:19 -0800 (PST)
Received: from [204.42.72.58] (helo=revelation) by srv0.ops.ietf.org with esmtp (Exim 4.10) id 18Ea96-000HpM-00; Wed, 20 Nov 2002 19:04:20 +0000
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>, "'Blake Ramsdell'" <[e-mail]>
Subject: Comments on draft-ietf-smime-rfc2632bis-02.txt
Date: Wed, 20 Nov 2002 14:03:29 -0500
Message-ID: <000b01c290c7$95883ae0$[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.2800.1106
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>

1.  Section 3, para 3:  There are two if present clauses in the
discussion of matching email addresses.  They appear redundent.

2.  Section 3, para 4:  How does a gateway signature verify "display" an
address on successful verification?  I don't like adding requirements
that are applicable only to display based UIs.

3.  Section 4.4.2, para 4:  Please change this to MUST reject the
signature.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAKIrBu01734 for ietf-smime-bks; Wed, 20 Nov 2002 10:53:11 -0800 (PST)
Received: from srv0.ops.ietf.org (srv0.ietf55.ops.ietf.org [205.238.48.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAKIr7g01727 for <[e-mail]>; Wed, 20 Nov 2002 10:53:08 -0800 (PST)
Received: from [204.42.72.58] (helo=revelation) by srv0.ops.ietf.org with esmtp (Exim 4.10) id 18EZyH-000HlN-00 for [e-mail]; Wed, 20 Nov 2002 18:53:09 +0000
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>
Subject: Comments on draft-ietf-smime-camellia
Date: Wed, 20 Nov 2002 13:51:19 -0500
Message-ID: <000a01c290c6$05c2ebe0$[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.2800.1106
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>

1.  Section 2.1: Remove the RECOMMENDED from the first sentence in this
paragraph.  You are only defining how to use CBC and thus should make
not statements about using some other mode.  (Unless you belive that
there are strong reasons for not using ANY other mode, and in that case
it should be MUST.)

2.  Section 2.1:  The last sentence can be replaced with the text.  "The
plain text is padded according to section 6.3 of RFC 3369."  The current
language is slightly confusing on when the padding needs to be done
relative to when the encryption is actually done.  The current language
seems to eliminate the possiblity of starting the encryption and just
padding when the last block is processed.

3.  As per another message, need the section on SMIMECapabilities.

4.  Please provide an ASN.1 module with all new items.  (Follow
procedures outlined on the IMC hosted page to get a module number.)

5.  Abstract:  I would like to see the alst sentence of the abstract
rewritten.  This is going to be an additional algorithm and as such
would not be included in the CMS specifications.  The text seems to
imply that the goal is to move this text into the replacements for RFC
3369 & RFC3370.  I can assure you this will not happen.  This algorithm
would be required to advance on it's own and could be referenced by
application documents in conjuction with a reference to RFC 3369.

6.  Please insert a new section between 1 and 2 which gives some history
about the development of Camellia.

7.  Section 2.2:  I strongly suggest that you change the parameters for
the key wrap algorithm OIDs to be ABSENT rather than NULL.

8.  Section 3:  Have you looked at any of the security the key wrap
algorithm for any holes?

9.  Security Considerations:  Please add the standard consideration
about protecting the Camellia key value.

Jim





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA8FDl628128 for ietf-smime-bks; Fri, 8 Nov 2002 07:13:47 -0800 (PST)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id gA8FDkv28123 for <[e-mail]>; Fri, 8 Nov 2002 07:13:46 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 8 Nov 2002 15:13:47 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA19395 for <[e-mail]>; Fri, 8 Nov 2002 10:13:46 -0500 (EST)
Received: from exeu00.securid.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id gA8FB3T14888 for <[e-mail]>; Fri, 8 Nov 2002 10:11:04 -0500 (EST)
Received: by exeu00.eu.rsa.net with Internet Mail Service (5.5.2653.19) id <W3JALS10>; Fri, 8 Nov 2002 15:17:51 -0000
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.48]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPWLFNW; Fri, 8 Nov 2002 10:13:40 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 08 Nov 2002 09:47:22 -0500
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: S/MIME WG Text Conferencing at IETF 55
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_8063584==_"
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>

--=====================_8063584==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

We are running an experiment at the IETF meeting in Atlanta.  This note is 
to find out whether the S/MIME WG wants to participate in the experiment or 
not.  The experiment is to determine if Jabber can be used during the IETF 
meeting to allow people who cannot come to Atlanta to participate.

Jabber conference rooms have been set up for each working group that will 
hold a session in Atlanta.  For the S/MIME WG, the conference room is:

     Group/Room: smime
     Server:     conference.ietf.jabber.com

I have attached the instructions for accessing the rooms, and so on.

If I do not get a volunteer to be the scribe, then we will not participate 
in this experiment.

Russ


--=====================_8063584==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="text-conferencing1.txt"

	     Remote Access for the 55th IETF meeting in Atlanta:
			     Text Conferencing

At each IETF meeting, two of the working group meeting rooms are equipped
for video multicast and remote participation.  That is, for every IETF
meeting slot, two of the working groups can see and hear the
meeting. For the 55th IETF, in *addition* to the usual network A/V, text
conferencing will be provided for every working group that meets.

All of the conference rooms will be hosted on

    conference.ietf.jabber.com

and each is named using the official IETF abbreviation found in the
agenda (e.g., "apparea",  "dhc", "forces", and so on -- for all the
examples that follow, we'll use "foobar" as the abbreviation).

Each conference room also has a 'bot which records everything that gets
sent. So, the minute taker can review this information right after the
meeting.
    
    
1. Before the meeting:

1.1. If you want to participate
    
If you don't already have one, get yourself a Jabber client, here are some
suggestions:

    platform	suggestion
    --------	----------
    win32	http://exodus.jabberstudio.org
    'nix	http://gabber.sf.net
    macos	http://jabberfox.sf.net

When you start the client for the first time, it will eventually ask if
you want to register on a public server. Go ahead and do
that. 
    
If you want to find out more, instead of choosing these defaults, here
are pointers to some additional information:
    
    list of clients:    http://www.jabber.org/user/clientlist.php
              howto:    http://www.jabber.org/user/userguide/
        server list:    http://www.jabber.org/user/publicservers.php

To make sure everything is running ok, do a "Join Group Chat" with your
Jabber client:
    
    Group/Room: testing
    Server:     conference.ietf.jabber.com

This conference room is up and running right now (although probably no
one will be in it when you connect).
    
1.2. What the Chair does
    
If you want to make text conferencing available, you'll need to have a
volunteer scribe in the meeting room. The scribe will be typing in a
running commentary as to what's going on in the room (who's presenting,
what question is being asked, etc.)
    
So, why not send an email out on the mailing list now, before the
meeting, to ask for volunteers?
    
    
2. At the meeting

2.1. What the Chair does

When a session starts, the chair asks if someone in the room is willing
to act as "scribe". If no one volunteers, read no further, we're done!

Otherwise, the scribe should do a "Join Group Chat" with their Jabber
client, e.g.,

    Group/Room: foobar
    Server:     conference.ietf.jabber.com


2.2. What the Scribe does

The scribe types in a running commentary as to what's going on in the
room. For example, if a speaker makes a presentation, the scribe types
in the URL for the presentation (more on this in a bit).

Simlarly, during question time, a remote participant can type a question
into the room and the scribe can pass it on to the speaker.


2.3. What each Presenter does

Each presenter should put a copy of their presentation on a web server
somewhere, so remote participants can follow along. 
    
If you don't have a server available, email your presentation to
    
    To: [e-mail]
    Subject: foobar
    
and the Secretariat will put the presentation in a server so it can be
accessed under:
    
    http://atlanta.ietf.org/presentations/foobar/
    
Don't wait until the last minute to send the email.
    

2.4. Where to find the conference log
    
    http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/foobar/
    
    
2.5. Finally
    
This is an experiment. Let's see how well it works and discuss it after
the meeting.
    
				  #######

--=====================_8063584==_--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA7KEfV22116 for ietf-smime-bks; Thu, 7 Nov 2002 12:14:41 -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 gA7KEcv22109; Thu, 7 Nov 2002 12:14:38 -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 PAA08965 for <1timer>; Thu, 7 Nov 2002 15:11:40 -0500 (EST)
Message-Id: <[e-mail]>
From: The IESG <[e-mail]>
To: All IETF Working Groups: ;
Subject: Note Well Statement
x-msg: NoteWell
Date: Thu, 07 Nov 2002 15:11:40 -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>

>From time to time, especially just before a meeting, this statement is to
be sent to each and every IETF working group mailing list.
===========================================================================

				NOTE WELL

All statements related to the activities of the IETF and addressed to the
IETF are subject to all provisions of Section 10 of RFC 2026, which grants
to the IETF and its participants certain licenses and rights in such
statements.

Such statements include verbal statements in IETF meetings, as well as
written and electronic communications made at any time or place, which are
addressed to

    - the IETF plenary session,
    - any IETF working group or portion thereof,
    - the IESG, or any member thereof on behalf of the IESG,
    - the IAB or any member thereof on behalf of the IAB,
    - any IETF mailing list, including the IETF list itself,
      any working group or design team list, or any other list
      functioning under IETF auspices,
    - the RFC Editor or the Internet-Drafts function

Statements made outside of an IETF meeting, mailing list or other function,
that are clearly not intended to be input to an IETF activity, group or
function, are not subject to these provisions.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA6BYIm26578 for ietf-smime-bks; Wed, 6 Nov 2002 03:34:18 -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 gA6BYHv26572 for <[e-mail]>; Wed, 6 Nov 2002 03:34:17 -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 GAA12758; Wed, 6 Nov 2002 06:31:48 -0500 (EST)
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-05.txt
Date: Wed, 06 Nov 2002 06:31:47 -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>

--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-05.txt
	Pages		: 0
	Date		: 2002-11-5
	
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-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-x400transport-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-x400transport-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-x400transport-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-x400transport-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 majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA6BYBC26560 for ietf-smime-bks; Wed, 6 Nov 2002 03:34:11 -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 gA6BYAv26555 for <[e-mail]>; Wed, 6 Nov 2002 03:34:10 -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 GAA12724; Wed, 6 Nov 2002 06:31:40 -0500 (EST)
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-x400wrap-05.txt
Date: Wed, 06 Nov 2002 06:31:40 -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>

--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		: Securing X.400 Content with S/MIME
	Author(s)	: P. Hoffman, C. Bonatti, A. Eggen
	Filename	: draft-ietf-smime-x400wrap-05.txt
	Pages		: 0
	Date		: 2002-11-5
	
This document describes a protocol for adding cryptographic signature
and encryption services to X.400 content.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-x400wrap-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-x400wrap-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-x400wrap-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-x400wrap-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-x400wrap-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 majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA6BY6a26547 for ietf-smime-bks; Wed, 6 Nov 2002 03:34:06 -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 gA6BY5v26542 for <[e-mail]>; Wed, 6 Nov 2002 03:34:05 -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 GAA12712; Wed, 6 Nov 2002 06:31:36 -0500 (EST)
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-examples-09.txt
Date: Wed, 06 Nov 2002 06:31:35 -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>

--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		: Examples of S/MIME Messages
	Author(s)	: P. Hoffman
	Filename	: draft-ietf-smime-examples-09.txt
	Pages		: 8
	Date		: 2002-11-5
	
This document gives examples of message bodies formatted using S/MIME.
Specifically, it has examples of Cryptographic Message Syntax (CMS)
objects, S/MIME messages (including the MIME formatting), and Enhanced
Security Services for S/MIME (ESS). It includes examples of most or all
common CMS and ESS formats; in addition, it gives examples that show
common pitfalls in implementing CMS. The purpose of this document is to
help increase interoperability for S/MIME and other protocols that rely
on CMS.
This draft is being discussed on the 'ietf-smime' mailing list.  To
join the list, send a message to <[e-mail]> with the
single word 'subscribe' in the body of the message.  Also, there is a
Web site for the mailing list at <http://www.imc.org/ietf-smime/>.

This draft is being discussed on the 'ietf-smime' mailing list.  To
join the list, send a message to <[e-mail]> with the
single word 'subscribe' in the body of the message.  Also, there is a
Web site for the mailing list at <http://www.imc.org/ietf-smime/>.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-examples-09.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-examples-09.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-examples-09.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-examples-09.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-examples-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA5BDkL07193 for ietf-smime-bks; Tue, 5 Nov 2002 03:13:46 -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 gA5BDjv07187 for <[e-mail]>; Tue, 5 Nov 2002 03:13:45 -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 GAA11342; Tue, 5 Nov 2002 06:11:16 -0500 (EST)
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-rfc2633bis-02.txt
Date: Tue, 05 Nov 2002 06:11:16 -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>

--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		: S/MIME Version 3.1 Message Specification
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-rfc2633bis-02.txt
	Pages		: 0
	Date		: 2002-11-4
	
S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a
consistent way to send and receive secure MIME data. Based on the
popular Internet MIME standard, S/MIME provides the following
cryptographic security services for electronic messaging applications:
authentication, message integrity and non-repudiation of origin (using
digital signatures) and data confidentiality (using encryption).

S/MIME can be used by traditional mail user agents (MUAs) to add
cryptographic security services to mail that is sent, and to interpret
cryptographic security services in mail that is received. However,
S/MIME is not restricted to mail; it can be used with any transport
mechanism that transports MIME data, such as HTTP. As such, S/MIME
takes advantage of the object-based features of MIME and allows secure
messages to be exchanged in mixed-transport systems.

Further, S/MIME can be used in automated message transfer agents that
use cryptographic security services that do not require any human
intervention, such as the signing of software-generated documents and
the encryption of FAX messages sent over the Internet.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2633bis-02.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-rfc2633bis-02.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-rfc2633bis-02.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-rfc2633bis-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-rfc2633bis-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA5BDfm07174 for ietf-smime-bks; Tue, 5 Nov 2002 03:13:41 -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 gA5BDev07168 for <[e-mail]>; Tue, 5 Nov 2002 03:13:40 -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 GAA11308; Tue, 5 Nov 2002 06:11:12 -0500 (EST)
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-rfc2632bis-02.txt
Date: Tue, 05 Nov 2002 06:11:11 -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>

--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		: S/MIME Version 3.1 Certificate Handling
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-rfc2632bis-02.txt
	Pages		: 0
	Date		: 2002-11-4
	
S/MIME (Secure/Multipurpose Internet Mail Extensions), described in
[SMIME-MSG], provides a method to send and receive secure MIME
messages. Before using a public key to provide security services, the
S/MIME agent MUST certify that the public key is valid. S/MIME agents
MUST use PKIX certificates to validate public keys as described in the
Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL
Profile [KEYM]. S/MIME agents MUST meet the certificate processing
requirements documented in this document in addition to those stated
in [KEYM].
This specification is compatible with the Cryptographic Message Syntax
[CMS] in that it uses the data types defined by CMS. It also inherits
all the varieties of architectures for certificate-based key
management supported by CMS.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2632bis-02.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-rfc2632bis-02.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-rfc2632bis-02.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-rfc2632bis-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-rfc2632bis-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4K2Yw22936 for ietf-smime-bks; Mon, 4 Nov 2002 12:02:34 -0800 (PST)
Received: from broadsword.its.cse.dnd.ca (itsfw.cse.dnd.ca [131.136.196.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4K2XW22931 for <[e-mail]>; Mon, 4 Nov 2002 12:02:33 -0800 (PST)
Received: by broadsword.its.cse.dnd.ca with Internet Mail Service (5.5.2653.19) id <V60JDYC9>; Mon, 4 Nov 2002 15:07:38 -0500
Message-ID: <[e-mail]>
From: [e-mail]
To: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-smime-camellia-00.txt
Date: Mon, 4 Nov 2002 15:07:36 -0500 
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>

I would suggest that similarly to RFC 2876 and RFC 2984 on the use of the
SKIPJACK and CAST-128 algorithms respectively in CMS, this Internet Draft
should also include a section addressing the SMIMECapabilities attribute
conventions for Camellia.

Cheers,

Francois

> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the S/MIME Mail Security Working Group of the
IETF.
>
>         Title           : Use of the Camellia Encryption Algorithm in CMS
>         Author(s)       : S. Moriai, A. Kato
>         Filename        : draft-ietf-smime-camellia-00.txt
>         Pages           : 5
>         Date            : 2002-10-31
>        
> This document specifies how to incorporate the Camellia encryption
> algorithm into the S/MIME Cryptographic Message Syntax (CMS) as an
> additional algorithm for symmetric encryption.  The relevant OIDs
> and processing steps are provided so that Camellia may be included
> in the CMS specification (RFC 3369, RFC 3370) for content and key
> encryption.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-smime-camellia-00.txt


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA1Dk6T28637 for ietf-smime-bks; Fri, 1 Nov 2002 05:46:06 -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 gA1Dk5W28633 for <[e-mail]>; Fri, 1 Nov 2002 05:46:05 -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 IAA06511; Fri, 1 Nov 2002 08:43:40 -0500 (EST)
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-camellia-00.txt
Date: Fri, 01 Nov 2002 08:43:39 -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>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Use of the Camellia Encryption Algorithm in CMS
	Author(s)	: S. Moriai, A. Kato
 	Filename	: draft-ietf-smime-camellia-00.txt
	Pages		: 5
	Date		: 2002-10-31
	
This document specifies how to incorporate the Camellia encryption
algorithm into the S/MIME Cryptographic Message Syntax (CMS) as an
additional algorithm for symmetric encryption.  The relevant OIDs
and processing steps are provided so that Camellia may be included
in the CMS specification (RFC 3369, RFC 3370) for content and key
encryption.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-camellia-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-camellia-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-camellia-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-camellia-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-camellia-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--