Re: UNSUBSCRIBE

[Natalia Syracuse <[e-mail]>]

Attention please!!!

To unsubscribe from the IETF Announcement list, send a message 
to [e-mail].

Enter just the word unsubscribe in the body of the message.

Natalia Syracuse

On Fri, 30 Mar 2001, John Greco wrote:

> UNSUBSCRIBE
> 




Received: by above.proper.com (8.9.3/8.9.3) id HAA22659 for ietf-smime-bks; Fri, 30 Mar 2001 07:20:54 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA22655 for <[e-mail]>; Fri, 30 Mar 2001 07:20:52 -0800 (PST)
Received: from NSYRACUS ([10.27.5.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20177; Fri, 30 Mar 2001 10:20:49 -0500 (EST)
Date: Fri, 30 Mar 2001 10:27:31 -0500 (Eastern Standard Time)
From: Natalia Syracuse <[e-mail]>
To: John Greco <[e-mail]>
cc: [e-mail], [e-mail], [e-mail]
Subject: Re: UNSUBSCRIBE
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
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>

Attention please!!!

To unsubscribe from the IETF Announcement list, send a message 
to [e-mail].

Enter just the word unsubscribe in the body of the message.

Natalia Syracuse

On Fri, 30 Mar 2001, John Greco wrote:

> UNSUBSCRIBE
> 



Received: by above.proper.com (8.9.3/8.9.3) id EAA08708 for ietf-smime-bks; Fri, 30 Mar 2001 04:31:00 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA08700 for <[e-mail]>; Fri, 30 Mar 2001 04:30: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 HAA10949; Fri, 30 Mar 2001 07:31:00 -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-pkcs1-00.txt
Date: Fri, 30 Mar 2001 07:31:00 -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		: Preventing the Million Message Attack on CMS
	Author(s)	: E. Rescorla
	Filename	: draft-ietf-smime-pkcs1-00.txt
	Pages		: 5
	Date		: 29-Mar-01
	
When data is encrypted using RSA it must be padded out to the length
of the modulus--typically 512 to 2048 bits.  he most popular tech-
nique for doing this is described in [PKCS-1]. However, in 1998 Ble-
ichenbacher described an adaptive chosen ciphertext attack on SSL
[MMA]. This attack, called the Million Message Attack, allowed the
recovery of a single PKCS-1 encrypted block, provided that the
attacker could convince the receiver to act as a particular kind of
oracle.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-pkcs1-00.txt

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-pkcs1-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-pkcs1-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-pkcs1-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-pkcs1-00.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.9.3/8.9.3) id MAA24038 for ietf-smime-bks; Thu, 29 Mar 2001 12:05:43 -0800 (PST)
Received: from capu.net (IDENT:[e-mail] [205.177.76.107]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA24034 for <[e-mail]>; Thu, 29 Mar 2001 12:05:42 -0800 (PST)
Received: from [64.50.216.55] (HELO ieca.com) by capu.net (CommuniGate Pro SMTP 3.4.3) with ESMTP id 7970061 for [e-mail]; Thu, 29 Mar 2001 15:05:43 -0500
Message-ID: <[e-mail]>
Date: Thu, 29 Mar 2001 15:05:35 -0500
From: "Bonatti, Chris" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: IETF S/MIME WG <[e-mail]>
Subject: Revised section 2.5 of draft-ietf-smime-x400transport-01
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id MAA24035
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>

    To briefly summarize what transpired in Minneapolis wrt this
draft, we mainly discussed the resolution of the certs-only issue
raised by Bill Ottaway.  The thrust was that he was uncomfortable
having an S/MIME type called "certs-only" that in practice might
admit either certificates or CRLs.  We seemed to have reached
consensus on altering language to make this a “cert managent “
type, rather than "certs-only" on the assumption that a
corresponding change would be made in the revised S/MIME Message
Specification (son-of-RFC2633).  Jim Schaad then noted that we
also need to add an smime-type value (and associated OID) for the
signed receipts and other defined values.  This seemed valid, and
nobody present objected.  I would therefore like to establish
some appropriately revised text covering the various S/MIME types
so that we can reissue the document.  To that end, I propose the
following as a new starting point.

    I hope this revised text is acceptable to all.  Otherwise,
well you know my address...  The plan is to revise the
x400transport draft and hopefully propose it for WG Last Call
around the time of the next meeting.

Cheers!
Chris


_____________________________

2.5 Encoded Information Type Indication

In [MSG], the application/pkcs7-mime content type and optional
"smime-type" parameter are used to convey details about the
security applied (signed or enveloped) along with infomation
about the contained content.  This may aid receiving S/MIME
implementations in correctly processing the secured content.
Additional values of smime-type are defined in [ESS] and
[X400WRAP]. In an X.400 transport environment, MIME typing is not
available.  Therefore the equivalent semantic is conveyed using
the Encoded Information Types (EITs).  The EITs are conveyed in
the original-encoded-information-types field of the X.400 message
envelope.  This memo defines the following smime-types.

     smime-type       EIT Value (OID)
     Security         Inner Content

     enveloped-data   id-eit-envelopedData
     EnvelopedData    Data

     signed-data      id-eit-signedData
     SignedData       Data

     cert-management  id-eit-certManagement
     SignedData       none

     signed-receipt   id-eit-signedReceipt
     SignedData       Receipt

     enveloped-x400   id-eit-envelopedx400
     EnvelopedData    X.400 content

     signed-x400      id-eit-signedx400
     SignedData       X.400 content

Sending agents SHOULD include the appropriate S/MIME EIT OID
value.  Receiving agents SHOULD recognize S/MIME OID values in
the EITs field, and process the message appropriately according
to local procedures.

In order that consistency can be obtained with future, the
following guidelines should be followed when assigning a new
values of EIT.  Values assigned for S/MIME EITs should correspond
to assigned smime-type values on a one to one basis.  The
restrictions of section 3.2.2 of [MSG] therefore apply.  S/MIME
EIT values may coexist with other EIT values intended to further
qualify the makeup of the protected content.

2.5.1 Enveloped Data

The enveloped data EIT indicates that the X.400 content field
contains a MIME type that has been protected by the CMS
Enveloped-data content type in accordance with [MSG]. The
resulting enveloped data CMS content is conveyed in accordance
with section 2.2. This EIT should be indicated by the following
OID value:

    id-eit-envelopedData  OBJECT IDENTIFIER ::=
        { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
        pkcs-9(9) smime(16) eits(***) envelopedData(0) }

2.5.2 Signed Data

The signed data EIT indicates that the X.400 content field
contains a MIME type that has been protected by the CMS
Signed-data content type in accordance with [MSG]. The resulting
signed data CMS content is conveyed in accordance with section
2.2. This EIT should be indicated by the following OID value:

   id-eit-signedData  OBJECT IDENTIFIER ::=
        { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
        pkcs-9(9) smime(16) eits(***) signedData(1) }

2.5.3 Certificate Management

The certificate management message is used to transport
certificates and/or CRLs, such as in response to a registration
request. The certificate management message consists of a single
instance of CMS content of type Signed-data.  The
encapContentInfo eContent field MUST be absent and signerInfos
field MUST be empty. The resulting certificate management CMS
content is conveyed in accordance with section 2.2. This EIT
should be indicated by the following OID value:

    id-eit-certManagement  OBJECT IDENTIFIER ::=
        { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
        pkcs-9(9) smime(16) eits(***) certManagement(2) }

2.5.4 Signed Receipt

The signed receipt EIT indicates that the X.400 content field
contains a Receipt content that has been protected by the CMS
Signed-data content type in accordance with [ESS]. The resulting
signed data CMS content is conveyed in accordance with section
2.2. This EIT should be indicated by the following OID value:

    id-eit-signedReceipt  OBJECT IDENTIFIER ::=
        { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
        pkcs-9(9) smime(16) eits(***) signedReceipt(3) }

2.5.5 Enveloped X.400

The enveloped X.400 EIT indicates that the X.400 content field
contains X.400 content that has been protected by the CMS
Enveloped-data content type in accordance with [X400WRAP]. The
resulting enveloped X.400 CMS content is conveyed in accordance
with section 2.2. This EIT should be indicated by the following
OID value:

    id-eit-envelopedX400  OBJECT IDENTIFIER ::=
        { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
        pkcs-9(9) smime(16) eits(***) envelopedX400(4) }

2.5.6 Signed X.400

The signed X.400 EIT indicates that the X.400 content field
contains X.400 content that has been protected by the CMS
Signed-data content type in accordance with [X400WRAP]. The
resulting signed X.400 CMS content is conveyed in accordance with
section 2.2. This EIT should be indicated by the following OID
value:

    id-eit-signedX400  OBJECT IDENTIFIER ::=
        { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
        pkcs-9(9) smime(16) eits(***) signedX400(5) }





Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id BAA02527 for ietf-smime-bks; Thu, 29 Mar 2001 01:34:28 -0800 (PST)
Received: from fep40-svc.tin.it (mta40-acc.tin.it [212.216.176.93]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA01092; Thu, 29 Mar 2001 01:26:44 -0800 (PST)
From: [e-mail]
Received: from [212.171.30.247] by fep19-svc.tin.it (InterMail vM.4.01.03.13 201-229-121-113) with SMTP id <20010329092548.VBWC8227.fep19-svc.tin.it@[212.171.30.247]>; Thu, 29 Mar 2001 11:25:48 +0200
To: [e-mail]
Date: Wed, 28 Mar 01 02:33:16 EST
Subject: toner supplies
Reply-To: [e-mail]
Message-Id: <20010329092548.VBWC8227.fep19-svc.tin.it@[212.171.30.247]>
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>

PLEASE FORWARD TO THE PERSON
RESPONSIBLE FOR PURCHASING
YOUR LASER PRINTER SUPPLIES


**** VORTEX  SUPPLIES ****

-SPECIALS OF THE DAY ON LASER TONER SUPPLIES AT DISCOUNT PRICES--

 
LASER PRINTER TONER CARTRIDGES
COPIER AND FAX CARTRIDGES

WE ARE -->THE<-- PLACE TO BUY YOUR TONER CARTRIDGES BECAUSE YOU
SAVE UP TO 30% FROM OFFICE DEPOT'S, QUILL'S OR OFFICE MAX'S EVERY DAY
LOW PRICES

ORDER BY PHONE:[phone]
ORDER BY FAX: [phone]
CUSTOMER SERVICE: 1-888-248-2015
E-MAIL REMOVAL LINE: 1-888-248-4930 

UNIVERSITY AND/OR SCHOOL PURCHASE ORDERS WELCOME. (NO CREDIT APPROVAL REQUIRED)
ALL OTHER PURCHASE ORDER REQUESTS REQUIRE CREDIT APPROVAL.

PAY BY CHECK (C.O.D), CREDIT CARD OR PURCHASE ORDER (NET 30 DAYS).


IF YOUR ORDER IS BY CREDIT CARD PLEASE LEAVE YOUR CREDIT CARD # PLUS EXPIRATION DATE. 
IF YOUR ORDER IS BY PURCHASE ORDER LEAVE YOUR SHIPPING/BILLING ADDRESSES AND YOUR P.O. NUMBER
C.O.D. ORDERS ADD $4.5 TO SHIPPING CHARGES.

FOR THOSE OF YOU WHO REQUIRE MORE INFORMATION ABOUT OUR COMPANY
INCUDING FEDERAL TAX ID NUMBER, CLOSEST SHIPPING OR CORPORATE ADDRESS IN THE
CONTINENTAL U.S.  OR  FOR CATALOG  REQUESTS PLEASE CALL OUR CUSTOMER
SERVICE LINE  1-888-248-2015 
 

OUR NEW , LASER PRINTER TONER CARTRIDGE, PRICES ARE  AS FOLLOWS: 

(PLEASE ORDER BY PAGE NUMBER AND/OR ITEM NUMBER)
                                 
HEWLETT PACKARD: (ON PAGE 2)
                                   
ITEM #1  LASERJET SERIES  4L,4P (74A)------------------------$44
ITEM #2  LASERJET SERIES  1100 (92A)-------------------------$44
ITEM #3  LASERJET SERIES  2 (95A)-------------------------------$39
ITEM #4  LASERJET SERIES  2P (75A)-----------------------------$54 
ITEM #5  LASERJET SERIES  5P,6P,5MP, 6MP (3903A)--$44
ITEM #6  LASERJET SERIES  5SI, 5000 (29A)------------------$95
ITEM #7  LASERJET SERIES  2100 (96A)-------------------------$74
ITEM #8  LASERJET SERIES  8100 (82X)-----------------------$145
ITEM #9  LASERJET SERIES  5L/6L (3906A0------------------$35
ITEM #10 LASERJET SERIES  4V-------------------------------------$95
ITEM #11 LASERJET SERIES 4000 (27X)-------------------------$72
ITEM #12 LASERJET SERIES 3SI/4SI (91A)--------------------$54
ITEM #13 LASERJET SERIES 4, 4M, 5,5M-----------------------$49

HEWLETT PACKARD FAX (ON PAGE 2)

ITEM #14 LASERFAX 500, 700 (FX1)----------$49
ITEM #15  LASERFAX 5000,7000 (FX2)------$54
ITEM #16  LASERFAX (FX3)------------------------$59
ITEM #17  LASERFAX (FX4)------------------------$54

LEXMARK/IBM (ON PAGE 3)

OPTRA 4019, 4029 HIGH YIELD---------------$89
OPTRA R, 4039, 4049 HIGH YIELD---------$105
OPTRA E----------------------------------------------------$59
OPTRA N--------------------------------------------------$115
OPTRA S--------------------------------------------------$165
-
EPSON (ON PAGE 4)

ACTION LASER 7000,7500,8000,9000-------$105
ACTION LASER 1000,1500-------------------------$105

CANON PRINTERS (ON PAGE 5)

 PLEASE CALL FOR MODELS AND UPDATED PRICES
 FOR CANON PRINTER CARTRIDGES

PANASONIC (0N PAGE 7)

NEC SERIES 2 MODELS 90 AND 95----------$105

APPLE (0N PAGE 8)

LASER WRITER PRO 600 or 16/600------------$49 
LASER WRITER SELECT 300,320,360---------$74
LASER WRITER 300 AND 320----------------------$54
LASER WRITER NT, 2NT------------------------------$54
LASER WRITER 12/640--------------------------------$79



CANON FAX (ON PAGE 9)

LASERCLASS 4000 (FX3)---------------------------$59
LASERCLASS 5000,6000,7000 (FX2)---------$54
LASERFAX 5000,7000 (FX2)----------------------$54
LASERFAX 8500,9000 (FX4)----------------------$54


CANON COPIERS (PAGE 10)

PC 3, 6RE, 7 AND 11 (A30)---------------------$69
PC 300,320,700,720 and 760 (E-40)--------$89

IF YOUR CARTRIDGE IS NOT LISTED CALL CUSTOMER SERVICE AT 1-888-248-2015 

90 DAY UNLIMITED WARRANTY INCLUDED ON ALL PRODUCTS.

ALL TRADEMARKS AND BRAND NAMES LISTED ABOVE ARE PROPERTY OF THE 
RESPECTIVE HOLDERS AND USED FOR DESCRIPTIVE PURPOSES ONLY.



Received: by above.proper.com (8.9.3/8.9.3) id LAA10552 for ietf-smime-bks; Tue, 27 Mar 2001 11:53:05 -0800 (PST)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id LAA10537; Tue, 27 Mar 2001 11:53:03 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 27 Mar 2001 19:50:48 UT
Received: from HOUSLEY-LAP.rsasecurity.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA23528; Tue, 27 Mar 2001 14:53:02 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender:  (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 27 Mar 2001 11:25:00 -0500
To: [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: Need an OID from the S/MIME arc?
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>

With the help of Paul Hoffman, we have set up a special mail address to 
obtain OIDs from the S/MIME arc.  Please send future requests for OIDs in 
the S/MIME arc to <[e-mail]>.  I have set up a filter in 
my mail client to flag messages that are sent to this address.  This should 
help me to handle OID requests efficiently and effectively.

As usual, the S/MIME OIDs are posted at imc.org.

Russ 



Received: by above.proper.com (8.9.3/8.9.3) id LAA07977 for ietf-smime-bks; Tue, 27 Mar 2001 11:02:57 -0800 (PST)
Received: from aeposmail.aepos.com (aeposmail.aepos.com [209.112.11.5]) by above.proper.com (8.9.3/8.9.3) with SMTP id LAA07971 for <[e-mail]>; Tue, 27 Mar 2001 11:02:56 -0800 (PST)
From: [e-mail]
Received: by aeposmail.aepos.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256A1C.006AD8EC ; Tue, 27 Mar 2001 14:27:03 -0500
X-Lotus-FromDomain: AEPOS
To: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 27 Mar 2001 14:27:02 -0500
Subject: virus warning - HAHAHA
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>

   The message obstensibly from [e-mail] is extremely likely to
contain a virus in the screen saver attachment.  See
http://www.sophos.com/virusinfo/analyses/w32hybrisb.html for more details.  This
one is apparently a Spanish update.




Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id FAA14296 for ietf-smime-bks; Tue, 27 Mar 2001 05:32:02 -0800 (PST)
Received: from mdevoto (hostdialup.interlink.com.ar [200.51.0.116] (may be forged)) by above.proper.com (8.9.3/8.9.3) with SMTP id FAA14284 for <[e-mail]>; Tue, 27 Mar 2001 05:31:51 -0800 (PST)
Date: Tue, 27 Mar 2001 05:31:51 -0800 (PST)
Message-Id: <[e-mail]>
From: Hahaha <[e-mail]>
Subject: Enanito si, pero con que pedazo!
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--VEKTA7C5E70P"
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>

----VEKTA7C5E70P
Content-Type: text/plain; charset="us-ascii"

Faltaba apenas un dia para su aniversario de de 18 años. Blanca de Nieve fuera
siempre muy bien cuidada por los enanitos. Ellos le prometieron una *grande*
sorpresa para su fiesta de compleaños. Al entardecer, llegaron. Tenian un brillo
incomun en los ojos...


----VEKTA7C5E70P
Content-Type: application/octet-stream; name="blanca de nieve.scr"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="blanca de nieve.scr"

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAgAAAALRMzSEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAABQRQAATAECAAAAAAAAAAAAAAAAAOAADwELAQAAAFYAAAAAAAAAAAAAABAA
AAAQAAAAAAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAACAAAAAAgAAAAAAAAIAAAAAABAA
ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAAhwAAAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAAAGAAAAAQAACoVAAAAAIA
AAAAAAAAAAAAAAAAACAAAOAucmRhdGEAAAAQAAAAcAAAWgAAAABYAAAAAAAAAAAAAAAAAABAAADA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADr
FqhUAABOSEJPR09NQgASBkhZQlJJUwD8aExwQAD/FQBwQACjCiNAAIPEhIvMUOh8AAAAXqE1Cifa
HPo3yJDnSLXJ7t3FOxTtOKRv+GfTc+pR9O6i/AuJNOIiPrxC4Cq53H5sNXfMXjVguFwJrFAYrHHj
SiXLG3Lv+wdKT1hwcrOTfD7rduGAY5LvseJ7FEQYpBTblO28PiFdANOtfu+nOGbHGCUuPV1gfpLV
ICaXTlFqH+jWCAAAagPHRCR8IIO47V0xLSsXQAAxLVEXQACLLQIQQABqQGgAMAAAVWoA/1QkSIXA
D4TKBAAAUFVQ/1QkSAEsJF+FwI21ABBAAA+FsQQAAGhMTAAAaDMyLkRoV1MyX1T/VCQwhcBYWFgP
hJIEAABQ/1QkKP2H6fOkxgfrgcc4AQAA/+f86L8HAADGhZwFAADrxoX0AQAAPImNmAUAAIHsBAEA
AIv0gcTA/v//aAQBAABW/5QkkAIAAIXAD4QiBAAAjTwGuFxXU0+rNR8cYH2rNW0Pf36rK8CrVFb/
lCSMAgAAi9hDD4T4AwAAK+1Q/5QknAIAADlsJBwPheQDAABqEotEJCQr0ln38YP6EA+ExQMAAGiA
AAAAVv+UJHwCAACFwHQcVWiAAAAAagNVVWgAAADAVv+UJHgCAACL2EB1butnaAQBAABqQP+UJLQC
AACFwHRV6PAGAADGhfQBAADriYWYBQAAxoWcBQAAPDP/l+iUCAAAV1bzpIPvC411BqWlq19eagFW
V/+UJMACAACFwA+FQv///8eEJLwCAAAAAAAAxoWcBQAA6+kWAwAAU4t0JCSBxgAAAQBVVlVqBFVT
/5QkdAIAAIXAD4TWAgAAUFZVVWoCUP+UJHACAACFwA+EnAIAAFD/dCQsUP+UJJQCAACFwIsEJA+F
fQIAAGAPtxgDQDxQaPgAAABQ/5QkuAIAAIXAWA+FXgIAADMY6CcGAACB8x0fAACLTQIPhUgCAABm
90AWACExQAgPt1gGD4Q1AgAAa9sojZQY+AAAAIt67Itq5Ita6AFK6AFK4MdC/EAAAMCLcDhOAXLg
99YhcuCLcug5cuBzBYly4OvnUYtK4ANK5IlIUFkD+41UHQCNqtASAAADfCQcUlXoqgUAAIv1UfOk
XSv9iZf3EgAAK/Vdh2goib7hAwAAia/jEgAAlYtEJFBqEgNNPEkDwffRVeh1BQAAA0UCI8Er0l1Z
9/GZQED34UhIiUQkUP90JCSNtQQBAAAPt00Gi314i9+tUCvYrSvYcgZYg+7g4u+tUOguBAAAMX8E
i38c6CMEAABeXofN6CIFAABbXlNqA7sgg7jtXY2GbgsAAIvQhwSvg+30K8KD6F2Jg8cLAACNhjYe
AACL0IcEr0Urwi3eAAAAiYMQHwAAjYbvEQAARYvQRYcEryvCLYEAAACJg2wSAACNhucSAACLk+MS
AAApg+MSAACF0nUGiZPjEgAAaAABAADocwcAAP7Egetw7P//iYN0////llKJk2////9fhf91Covy
ibN0////6x0DuQwBAAAruQQBAAADPCSLB4lDzGr/6DMHAACJA4fx4wgAB67ByAji+IfxW4lxWIm0
JOgCAACLbCRMh/NVh83R6WatZgPQZoPSAOL1WAPCiUVY6CkEAACAvfQBAAA8dFCNtCRsAQAAagRW
/7WYBQAA/5Qk2AIAAIXAdS5obWUAAGhSZW5hi8xoSU5JAGhOSVQuaFdJTklU/7WYBQAAVlH/lCTs
AgAAg8QUxoWcBQAA62H/lCS8AgAA/5QkaAIAACvtVVX/dCQs/3QkDP+UJIQCAAD/NCT/lCSUAgAA
jUQkGFCD6AhQg+gIUP90JAz/lCSMAgAA/5QkZAIAAI2cJEABAAD/NCRT/5QkfAIAAOsLx4QkvAIA
AAAAAABo6ABRADwK/zQk/5QkwAIAAP+UJHACAACBxEQCAAC/BAEAACvni9wr54vsV1VqAP+UJHgC
AABXU/+UJFQCAACLyIvRi/uL9aw6B3QGNCA4B3UDR+LyjTwTsFyquFBFT0eruEFCR0GruNG6p7r3
0KsrwKuDvCSAAgAAAA+EaAEAAIXJD4S5AAAAagNoAAAAgFXoqAEAAIvwQA+EkAEAAGgAAAIAakD/
lCR4AgAAi/hqAOixAgAAge16+f//VWgAAAIAV1b/lCRoAgAAVv+UJCgCAABqAmgAAABAU+heAQAA
i+hAdFWNtCQAAQAAagBWaCCDuO1XVf+UJGwCAABQUGr/av/oLQUAAA+30OglBQAAD7fAgOQPgMQe
VFJQ/5QkfAIAAIvEUFBQVf+UJFQCAABYWFX/lCQoAgAAV/+UJDQCAABqAGhQSTMyaEFEVkFU/5Qk
OAIAAFlZWWhRPE7OaF7Stp5o2bCuwovMg+wMi9RQUVJqA+h/AgAAXltfg8QMVFRoBgACAGoA6NoB
AACB7f73//9VaAEAAIBWi/VqEFmBNiCDuO2t4vde/9ZahcB0FlBUaAYAAgBqAFVoAgAAgP/WhcBa
dWlSjbQkCAEAAFboUwMAAIcMJFFqAWoAagBS/9P/14HxIIO47YXJdUKL7GoEagBV/5QkcAIAAIXA
dTBoTlVMAIvMaG1lAABoUmVuYYvUaElOSQBoTklULmhXSU5JVFVRUv+UJIgCAACDxBiBxAgCAAD/
NCT/NCTCdAArwFBogAAAAP90JBRQagP/dCQc/3QkHP+UJEwCAADCDAADfCQEK3wkCAN8JAzDc+ze
mVfiyoh8ztGOUuzLgkb35LpJ7dyCV/DkrlXxyohO9+6IUvDRgk7f6phOzNaORYO47Qjgkc125tuD
QYO47WCH/ovui10Ai3UEM8mLxsHgBIvWweoFM8KL1jPRA8KL0YPiAwMElwPYgcG5eTeei9PB4gSL
w8HoBTPQi8MzwQPQi8HB6AuD4AMDFIcD8oH5IDfvxnW3iV0AiXUEYcNgh/6L7otdAIt1BLkgN+/G
i9PB4gSLw8HoBTPQi8MzwQPQi8HB6AuD4AMDFIcr8oHBR4bIYYvGweAEi9bB6gUzwovWM9EDwovR
g+IDAwSXK9iFyXW7iV0AiXUEYcPoAAAAAF2Bxf72///DQetW89CFLt9rmvNIEg6q973wG3KAvaix
UJTSRed0Rce/4CEZ5ZsiSo/xDNA2CYvMLHIzMkfPsppRi4ToHGuYCPg9hG/7sX0zDw56vkBpng2X
JvfX7qX5do2hPCAR+S1lusPlQWOkYLA4bev3UoepJgqI5W08F0qVd3tDEzOPh2wAAAAAi1QkEIty
PI10MniLNo10FhitUK1QrZNdWa2Wh/P32ivyK+or2iv/R61gK8KWagBZrITAdBQyyLAI0elzBoHx
IIO47f7IdfLr54t0JCyLVCQkh9GtK8J0CeL5YUl1ycIQAE8PtwR7i0SFAANEJDCLdCQoSYkEjuvi
TThakDgDZgIECXH/gbjCkQFAwhXGgAkOtEzNIRUB6xhQRQhMAVMCFM7gAw8BC5VsKRCmBKWeKAzI
bwTvFCziApwH3FPpCMpHWz4DCOfSKAoB9UAudGV456sOkck8B+AgkgsHLnJkYXQqJFFaSkzSTg7A
FQH/qu/gzP8l4BBwQXQ4VAEPMNUQG8pMDDUgLzdWMDsRgEdldE1vZHV3bB1IYW72DJbgSxxFUk7D
TDMyLnEemwd3UwAAVlAryayEwHQDQev4WF7DYIt0JCSLfCQo/LKApOhoAAAAc/gzyehfAAAAcxoz
wOhWAAAAcyBBsBDoTAAAABLAc/d1PKrr1uhKAAAASeIQ6EAAAADrKKzR6HRLE8nrHJFIweAIrOgq
AAAAPQB9AABzCoD8BXMGg/h/dwJBQZWLxVaL9yvw86Re65MC0nUFihZGEtLDM8lB6O7///8Tyejn
////cvLDK3wkKIl8JBxhwggAYOgjAAAAi2QkCGRnjwYAAMcEJEwnAADoc/3///+VzBIAAGH5G8DC
DAAr22T/M2SJI4tEJDBmi1gCU4tABFBqAuh0EAAAWFtyB6kIAAAAdbpkZ48GAABYYemXaP//VVFS
uOsLbwW5bU7GQffhBTkwAAAl////B+gU/f//iYXPCwAAi0wkECvS9/GSWlldwgQAyAgBAGD8i30Q
i9czwLkgAAAA86v/Aot1FI29+P7//7kgAAAA86WLRQzorAIAAIld/MdF+AAAAACH24tFDItV+A+j
EHMIi1UQ6BkAAACNlfj+///oDgAAAP9F+P9N/HnaYcnCEACQjb14////M8CJB4lHBIlHCIlHDIlH
EIlHFIlHGIlHHIlHIIlHJIlHKIlHLIlHMIlHNIlHOIlHPIlHQIlHRIlHSIlHTIlHUIlHVIlHWIlH
XIlHYIlHZIlHaIlHbIlHcIlHdIlHeIlHfI2F+P7//+gCAgAAh9vRJ9FXBNFXCNFXDNFXENFXFNFX
GNFXHNFXINFXJNFXKNFXLNFXMNFXNNFXONFXPNFXQNFXRNFXSNFXTNFXUNFXVNFXWNFXXNFXYNFX
ZNFXaNFXbNFXcNFXdNFXeNFXfOisAQAAjYX4/v//D6MYD4PFAAAAiwKLSgQBBxFPBItCCItKDBFH
CBFPDItCEItKFBFHEBFPFItCGItKHBFHGBFPHItCIItKJBFHIBFPJItCKItKLBFHKBFPLItCMItK
NBFHMBFPNItCOItKPBFHOBFPPItCQItKRBFHQBFPRItCSItKTBFHSBFPTItCUItKVBFHUBFPVItC
WItKXBFHWBFPXItCYItKZBFHYBFPZItCaItKbBFHaBFPbItCcItKdBFHcBFPdItCeItKfBFHeBFP
fOjaAAAAh9tLD4nB/v//iweLXwSLTwiLdwyJAolaBIlKCIlyDItHEItfFItPGIt3HIlCEIlaFIlK
GIlyHItHIItfJItPKIt3LIlCIIlaJIlKKIlyLItHMItfNItPOIt3PIlCMIlaNIlKOIlyPItHQItf
RItPSIt3TIlCQIlaRIlKSIlyTItHUItfVItPWIt3XIlCUIlaVIlKWIlyXItHYItfZItPaIt3bIlC
YIlaZIlKaIlybItHcItfdItPeIt3fIlCcIladIlKeIlyfMOH27v/AwAAD6MYcgNLdfjDh9uLdQiL
R3yLTnw7wXLwD4c1AgAAi0d4i054O8Fy4A+HJQIAAItHdItOdDvBctAPhxUCAACLR3CLTnA7wXLA
D4cFAgAAi0dsi05sO8FysA+H9QEAAItHaItOaDvBcqAPh+UBAACLR2SLTmQ7wXKQD4fVAQAAi0dg
i05gO8EPgnz///8Ph8EBAACLR1yLTlw7wQ+CaP///w+HrQEAAItHWItOWDvBD4JU////D4eZAQAA
i0dUi05UO8EPgkD///8Ph4UBAACLR1CLTlA7wQ+CLP///w+HcQEAAItHTItOTDvBD4IY////D4dd
AQAAi0dIi05IO8EPggT///8Ph0kBAACLR0SLTkQ7wQ+C8P7//w+HNQEAAItHQItOQDvBD4Lc/v//
D4chAQAAi0c8i048O8EPgsj+//8Phw0BAACLRziLTjg7wQ+CtP7//w+H+QAAAItHNItONDvBD4Kg
/v//D4flAAAAi0cwi04wO8EPgoz+//8Ph9EAAACLRyyLTiw7wQ+CeP7//w+HvQAAAItHKItOKDvB
D4Jk/v//D4epAAAAi0cki04kO8EPglD+//8Ph5UAAACLRyCLTiA7wQ+CPP7//w+HgQAAAItHHItO
HDvBD4Io/v//d3GLRxiLThg7wQ+CGP7//3dhi0cUi04UO8EPggj+//93UYtHEItOEDvBD4L4/f//
d0GLRwyLTgw7wQ+C6P3//3cxi0cIi04IO8EPgtj9//93IYtHBItOBDvBD4LI/f//dxGLB4sOO8EP
grr9//93A4fbkIsGi04EKQcZTwSLRgiLTgwZRwgZTwyLRhCLThQZRxAZTxSLRhiLThwZRxgZTxyL
RiCLTiQZRyAZTySLRiiLTiwZRygZTyyLRjCLTjQZRzAZTzSLRjiLTjwZRzgZTzyLRkCLTkQZR0AZ
T0SLRkiLTkwZR0gZT0yLRlCLTlQZR1AZT1SLRliLTlwZR1gZT1yLRmCLTmQZR2AZT2SLRmiLTmwZ
R2gZT2yLRnCLTnQZR3AZT3SLRniLTnwZR3gZT3zD6AcAAAC8IIO47etoZGf/NgAAZGeJJgAAYOjw
9v//iaX1EQAAahBfK+eLxFdUUP90JEj/lcQSAABYD7dEJAID54DsGXUvi3QkMIvui0QkNCvHdiGt
Jd/f3981UkNQVK11EyX/39//NSBUTzp1B6xW6AoWAABhZGePBgAAWOnIZP//G2vHiJi92YfYoPwy
IAMBOJtmQc4YySe0yvC5beWUf0NhJqPpsY2ceNHlN4YuwR1jWkjkda+J5HVpc+R1S4zkddKf5HW0
oeR1oJLkdaCW5HWER+R184zkdSNn5HUpZ+R1g3wkCAF0FoN8JAgAD4QnBQAA6RZg//9qAVjCDABg
6Ar2//+L/YHvAKAAAIvfgcf9EgAAuewBAABgaAAA97+Nhe8hAABQg8BwUGoc6G72//9oTEwAAGgz
Mi5EaFdTMl9U6Mj1////lXsiAACDxAyJhTsYAABQjYVwEgAAUIPAMFBqDOg39v//YeNMgT9Vi+yB
dESL8cHhAmoAVGoAVGoEUVf/lcsiAACJhYsTAACHrWMiAABQi9n/1VNXaP///3+4tezQBofOKAfB
yAiu4vj/1V3oV/X//2gAAQAAakD/lbciAACJhYgfAAD/lZciAACJhc8LAAAryWog6P33//+R043H
GAAAuIABAADooQ0AAImNRhgAAFCJhUgcAAAFgAEAAOjZDgAAi10CA92D6wyL04t6CCvfRw+EsQAA
AGogT1mLtUgcAACLAjlGBHUpi0IEOUYIc9ZggcQc////VIiNxRgAAOhxBAAAVP+VvyIAAIHsHP//
/2GDxgziy2ogWYHsOQEAAFToTwQAAFT/lWsiAABAdAr+hcUYAADi6OtEYFCLxGoAUFcr/1ONdCQ0
V2iAAAAAagJXV2gAAADAVv+VqyIAAIvYU/+VfyIAAFP/laciAACLhUgcAACHBCToHg4AAGGB7Mf+
///pPv///411Biv/VldqAv+VgyIAAIXAdRKLzrgQAAAA6GsMAACH+YkI6xaXahBQUGoCV/+VjyIA
AIXAD4QLAwAAib0nGAAAiYUsGAAAjUUKK/9QV2oC/5WDIgAAhcAPhYgCAAD/dQKNTQq4BAABAOgc
DAAAiY0YGAAABASJhSYfAABQUI2FBgoAAFDohfX//4v1X1bogRMAAA+CEQEAAItFAgPwi0b8QHQH
g8AK99Dr8YvGKwQkiUUCaADAAABqQP+VtyIAAIXAD4TiAAAAVw+67R+Xi/eHdCQEi40CAACA86Rq
IGj/AAAAWg+2hRAAAIDR4CvQi7VIHACAWYvZOH4ED4SWAAAAav/oBvb//zrCD4OHAAAAYCvZi8uB
7AQBAABU6LQOAACL1CvbU2iAAAAAagNTagFoAAAAgFL/lasiAICL2EB0TGoAU/+VbyIAgIvI4ziL
lCQoAQAAA0ICPQCAAAB3J4PADIlCAomFAgAAgFCLxGoAUFFXA/lT/5WjIgCAi0YEq4tGCKtYq1P/
laciAICBxAQBAACJPCRhg+70SQ+FV////1+LhQIAAIC5IItFAovIXovfgccAAgAAV/Okx4PLCQAA
/zQk/8eDzwkAADQkwnQPuvUfYHMJK/BW/5WzIgAAYYHH/wEAAIHnAP7//4sUJI2yAPwAAIPHBFcr
+ofXiZOcAAAAiYOIAQAAgcIAAgAAiZO0AQAAjYIAAgAAiUP8iYXyHAAAgcL/DQAAgeIA8P//jYII
EAAAiYMAAQAAiZOAAQAAgcIAEAAAiZOsAQAAgcIAEAAAiZPQAAAAgcIA4P7/ARYBVggBVhQBVhgB
VjBo/wEAAFlf86ReBUQAQACJRhqDwLSJRiCB7g36///+hhz6///oOQAAAIPu+ugxAAAAgcYN+v//
6CYAAACt6CAAAABq/+hX9P//iYa9GAAAj0UC/7UmHwAAagHonQQAAFjrP2r/6Df0//8BBoEmDw8P
D4EGQUFBQcOJhRgYAABoAAABAFdXagJQ/5WPIgAAhcB0RovwrYm1Jh8AAImF8hwAAOgAEQAAcgyN
hcQhAABQ6HAJAACNhWcfAABQ6GQJAACNhesYAABQ6FgJAACB7ezg//9V6EwJAABh6dn6//9g6O7w
//+H9YHGJh8AAGisAAAAgwb8/zboqgkAAGioAAAAaACQbILomwkAAOjD8P//aAAA5HX/lXciAABo
jAAAAP+1SBwAAOh7CQAAi7WIHwAAVmogWa2L0K2F0nQHUFLoYgkAAOLv/5WzIgAA64tg6H/w//9o
8EkCAP+VuyIAAI2FkiQAAFD/tUgcAAD/dCQs6IgDAABYWGHCBAD5YGY9YPiLfCQkchNoBAEAAFfo
QfD///+VhyIAAAP4sSC69IVFBNPKagxZsFyqi8GKwiQPBEGqwcIE4vSID8ZH/C5hwgQAYGgAAAEA
akDoBfD///+VtyIAAIXAD4THAgAAUCvJiYgAeAAAi1UIiZAA+AAAi1UGiZAE+AAAx4AI+AAALkVY
RYmIDPgAAFBqCOjuAgAAWBvJUYt8JASBxwD8AABqHuh98v//uS0tVkWRq2aDwQVqJOhr8v//PBpy
BAQWZj0EQari7IvBq4t0JASBxgB4AACLBCSFwHUGrITAdftOi/7oPQAAAE1JTUUtVmVyc2lvbjog
MS4wDQpDb250ZW50LVR5cGU6IG11bHRpcGFydC9taXhlZDsgYm91bmRhcnk9IgBe6NMBAADo3QEA
AE9PuCINCgCrT+jJAQAAiwQkhcB1UOgxAAAAQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy
c2V0PSJ1cy1hc2NpaSINCg0KAF7ofQEAAIt0JATodAEAAGa4DQpmq+hyAQAA6C8AAABDb250ZW50
LVR5cGU6IGFwcGxpY2F0aW9uL29jdGV0LXN0cmVhbTsgbmFtZT0iAF7oLwEAAIt0JASBxgD4AADo
IAEAAOhSAAAAIg0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogYmFzZTY0DQpDb250ZW50LURp
c3Bvc2l0aW9uOiBhdHRhY2htZW50OyBmaWxlbmFtZT0iAF7owwAAAIt0JASBxgD4AADotAAAALAi
qrgNCg0Kq+j/7f//i4XyHAAAi7UmHwAA6JYIAAAD+eiXAAAAx0f+LS0NCsdHAgAAAABYgSwkAIj/
/2Doy+3//2gBAQAAK8Be6KsLAAByVSvmVFb/lbASAACFwHVBVOh8AAAAgDwkAHQvi/ToW+///2oA
UVbozQMAAGoAUOgxDAAAchVqAVDoJwwAAP+0JCEBAABW6BkJAAD/lbQSAACBxAEBAABoIL8CAP+V
uyIAAGHriKyEwHQDquv4w7gNCi0tq1ZRi3QkEIHuAAT//+jg////ZrgNCmarWV7DYcIEAGDoJu3/
/4uNbygAAOP4/41vKAAAi3wkJIu1LBgAAIsGhcB0J1BQ/5VfIgAAhcBYdRqLAIcGi/CtUK2HBCRQ
6Knu///zpJHotAUAAKr/hW8oAABhwgQAYOjQ7P//K8nGhXkcAAD5xoVuHAAA68eFdBwAABAAAAC+
AKD2gYHsEwEAAIvUrYWEJDcBAAB1IIPGCP7BgPkgcuyB7O3+///rCMdEJCggg7jtYfnCBAAtUlFW
iI3FGAAAUlLoG/z//+jgAgAAXllacsbGhXkcAAD4i4QkNwEAAGDoCwAAALwgg7jtgwwkAutlZGf/
NgAAZGeJJgAAg8TsiaWtHAAAiQQkqSAAAAB1DqlAAAAAdQepAgAAAHQNi4QkewEAAIlEJAjrCbgg
g7jtiUQkCIuEJHcBAACJRCQEi4WfIgAAiUQkDIuFmyIAAIlEJBBU/9fo3Ov//4sEJKgEdQaoAnQC
DECogHVOqAF0NYO9dBwAAAh0CseFdBwAAAEAAADGhW4cAAA890QkOAEAAAB0EYtMJAiJjfIcAACL
fCQEiU/8qAh0EcaFbhwAADzHhXQcAAAIAAAAqEB0Cv90JDD/lb8iAACDxBRkZ48GAABY/zQk/5Wz
IgAAYem3/v//YIPsKIt0JFSNfhClpaWli2wkVItMJFCLVCRMwekDjXUQrYkEJPfQiUQkGK2JRCQE
99CJRCQcrYlEJBCJRCQgrYlEJBSJRCQkiwKJRCQIi0IEiUQkDIPCCI10JAiNfCQY6Dbq//+LBzFF
EItHBDFFFIv0jXwkIOgg6v//iwcxRRiLRwQxRRziloPEKGHCDADoGQAAAItkJAjHRCQg/////2Fk
Z48GAACDxATCEABkZ/82AABkZ4kmAAD/dCQY/3QkGP90JBj/dCQY6JoAAABgkePOQXTLg+kgdsaD
wRCLdCQwrDxAdATi+eu2i/4r7U9F6EYAAAByB4P9DHbyK+2D/QRy4yvti9eL/kdFg/0Uc9aAPy51
9IB/BC507oB/Ay506IPHBegSAAAAcghP6AoAAABzs1LojQkAAOuruz06LCDBywg4X/90HoB//wB0
GIB//350EoB//zx0DIB//z50BoD7PXXbqPnD6X5X//9gaOCTBADo3un///+VuyIAAGgEgM2CagTo
9vz//13r/mHCBABgi1QkJItMJCiLRCQs4xj30DICQrMI0ehzBTUgg7jt/st18+Ls99CJRCQcYcIM
AGBqQOgJ+f//YcIEAGDohOn//8aFQiEAAPkPtoXFGAAAuawyQwCNBMGJRCQciwjjJr8AAAEAV2pA
i/H/lbciAACFwA+EkwEAAJeRV/OkX4k8JOkIAQAAK8BQaIAAAABqA1BqAWgAAACAUv+VqyIAAIvw
QA+EYwEAAL8AAAEAV2pA/5W3IgAAl4X/D4RMAQAAU4vcagBTUFdW/5WjIgAAhzQk/5WnIgAAg/5/
D4IrAQAA98YPAAAAD4UfAQAAiTwkV41UNxCDxoCNHDdWgcR4////i/xXahFqIFlYqyvA86tfU1JX
jYUKCQAAUOio6///gcSIAAAAiwwkwekDi3wkBIvyg+qA6DDo//+DxwiDxhA78nIGge6AAAAA4ulZ
iwQkgeqAAAAAUlFQi0IQi1oUi0oYi3oc6Af9//8zehxfD4WYAAAAM0IQD4WPAAAAM1oUD4WGAAAA
M0oYD4V9AAAAge0h3///VWT/MWSJIVRFj0UAahBU/9dd6we8JNXEAOsM6BLo///GhUIhAAD4ZGeP
BgAAXYdEJByJXCQQiUwkGIl0JASLCOMC6zOLNCRQgewAAgAAVOiG9///jUwkAbgAAAEA6BoAAACB
xAACAACL+FiJOIlIBLkAAAEA86T5YcIEAFFQ6DsAAADDYFQr7VRqBFX/dCQ0VVXom+f///+VryIA
AJHjEFFq8VH/lcMiAAD/lcciAABYYcIEAGoAUOgBAAAAw2Dobuf//yv//3QkKP90JChXagRXav//
lYsiAACFwHQTiUQkGP90JCRXV2oCUP+VjyIAAIlEJBxhwggAYGog6Kz2//9hwgQAYOgn5////3Qk
KIHtbd3///90JCj/VQD/VRRhwggAaBnraRnWeKdDCf5IlCfaHPq1GtAI3cU7FOt24YDfwL/rlO28
PhikFNu53H5sJS49XThmxxiX35cgSLXJ7q1+76chXQDTNWC4XNhJ4jG8QuAq4nsURGOS77Gzk3w+
ifB8zFHTe1dmQlbdRk+jsS3TEzoYzve/AKDedQ4P+r8we/e/sW/3vztx97/N4Pi/0Hb3v9Fv97/h
Evq/Qnn3v5p297+pIPi/ST34vzhq97+obfe/Fnf3vzlw979t4Pe/23r3v2Zv9789bve/tEj3vwgt
+b/1Gfq//PT4v68P+b9HY/m/YIHsEwEAAIu8JDcBAAArwFdqYFnzq1/oEub//4hFEIHtO+f//4hF
AIvUV1JS6Kj1///obfz//3MeX4PHDFT/lfoJAAD+RQCAfQAgctuB7O3+//9hwgQA/oVL5///hzwk
lquTq5Gr/5XuCQAA69Zg6Lrl//9Vge1Y7f//6A0AAABddUroGgAAAHTqdT/oagD/dCQ4/3QkOP90
JDj/VQCL2EPD/5XIEgAABc3Y///DuWDoeeX//1WBxaQSAADozP///111CejZ////dOr5sPiJRCQc
YcIMAPxXagPoRAAAAEFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaYWJjZGVmZ2hpamtsbW5vcHFy
c3R1dnd4eXowMTIzNDU2Nzg5Ky8AAAAAW1mZiVQLPffxi8hSrU6L0Og9AAAA6FYAAADoXgAAAOLr
WeMhrUl0Dw+30OgiAAAA6DsAAADrCg+20OgTAAAAQUGwPfOquA0KAABmq1kr+YfPw+gGAAAA6AgA
AADDi8LB6ALrHovCwOAEwOwECsTr8ovCwegIwOACwOwG6++LwsHoECQ/16qLQ0BAiUNAYGpMWZn3
8YXSYXUGZrgNCmarw2DoZeT//4iNxRgAAOkH9P//YGoAagFqAuhO5P///5W4EgAAi9hAD4QoAgAA
U4HsAAEAAIv8i7QkKAEAAKwsQHX7uHNtdHCrNF2q6Nzl///jIvOkkapU/5XAEgAAkYXJdRJUgcEe
DB0cMUwkBP+VwBIAAJGB7AD///+FyQ+EqAEAAItBDPj1lq1y+1Ir21NTUGgCAAAZi9xqEFP/dCQc
/5WsEgAAg+zwhcBaD4WZAQAAgeynAQAAi+xopwEAAFX/tCSvAQAA6OH9//8PgnMBAABVuAEHDQlo
AAEAAIv9NUlCQUarLSg4Qk+qi/dW6Hrj////laASAACFwHUH6Cvl//8D+Wa4DQpmq10r/ejZAAAA
agbHRQBSU0VUx0UEDQoAAF/owwAAALgE/wcGi/0FSUJBRqs1bQcbA2oPqzVtfHJzqzVzNyo8q1/o
nAAAALibhZGai/0tSUJBRqs1chcfbquA9Ghmq4u0JM8BAADouuT//+MC86Q1HjFFOqtPK/3oZgAA
AGoGgXUAdnRkYWbHRQQNCl/oSgAAAFWLtCTXAQAA6Ibk///jFFFW/7QkswEAAOg3/f//D4KHAAAA
XWoFx0UADQouDWbHRQQKAF/oGAAAAGoGgXUAY2B5dGbHRQQNCl9VuDM1NCDrBbgyNTAgVeh34v//
iYW0JgAAXVdV/7QkswEAAOjj/P//cjdopwEAAFX/tCSzAQAA6I78//9yI4F9ACCDuO11GsNqAFRq
/2oC6GD1//9YWFnjD3INkelI/v//XYHEpwEAAOgd4v///5W8EgAAYcIIAGDoDeL//2oJ6CQAAABy
wuuscMqL3w7H9KEgg7jtcuLLqE721a5P7daIQ/fRgk7w+e3obgAAAP80JP80JP+VeyIAAF6FwJZ0
OYPAEFBW/5WbIgAAhcB0KoHsmAEAAGicAQAAi+xonAEAAIvMVFRRVf/QXYHEoAEAAIXAdQUrxXQB
qPnoHQAAAFhYnFbog+H///+VdyIAAGjA1AEA/5W7IgAAnWHDnGCLdCQoi0wkLIE2IIO47a3i92Gd
w2CBxPz+//+L/GgEAQAAV+hF4f//xoVlKAAAPP+VhyIAAFcD+I11BmpcWKrB6Ailpapfi/BQagJq
BFBQaAAAAMBX/5WrIgAAi9iBxAQBAABAdHI5dCQodCFqAlZWU/+VcyIAAFCLxFZQagSNRCQ0UFP/
lX8iAABY60FqAFP/lW8iAACR4zVQi8RWUFFRakD/lbciAACL+FBT/5WjIgAAWcHpAleLRCQo8q90
AuMHxoVlKAAA6/+VsyIAAFP/laciAADrAaj5YcIIAGC5AQAAAOP56IPg//+B7ZHX////TQCLdCQk
K8msPCJ0EzwNdA88CnQLPD50B4TAdANB6+jjJ1GD6fCLwejS+P//hcBadBeLtb3v//+L+IcGq4fK
kquLdCQk86SRqv9FAGHCBABgg+wQVOgi4P///5VnIgAAWltYWMHrEA+322aB6tAHcncPt8rB6hAP
t8L2wQN1AUPjCIHDbQEAAOLwi9FIdD+Dwx9IdDmDwxxIdDODwx9IdC2Dwx5IdCeDwx9IdCGDwx5I
dBuDwx9IdBWDwx9IdA+Dwx5IdAmDwx9IdAODwx6D6xXR47g7AAAAk/fzhdJ0CEp0BYD6OXUBqPlh
w/////8Of/iCZ1rO1lQLHKLL6PnZ9/W4DG58rlCoQRphfqwsp1hQ3+hNMdkFSalSkbpAa4KNV84U
xu13Sg42Mn0ON8tfnF/QCijk11cA6Vy8Z6BzEVpV5jt+mA8wYrzuBIexgJ2iXKNM/RX6j2LE9L+P
YLq7xBw1osZP+Ri57sB00ckwRttJLxL50ChFlpqJwR7J5aRZxDwd7LbRv32ULIef976o5B4Gfb1j
yp6mSW001bfCEiXGdb498+Y+h7J4dgfMfc3uy6N89mjZjKFlGjT6+3W+fG9aBMgUMi6B7994rf83
T/w9Ojv13aGfjy1nx56sf+HamjWlyuWgT6lkAj/M7YzxjAScKsk0pJtWnkFHY8AZixPnR+djFd6J
d4HFUU60ZJxpyVuDlQHaukgswUbF1fzOEtwIMX/fSLNmFkZjCy8wJp1KPrU7/u2/CpDT6CQkBeH6
CCV/F0ceaNERGx75QhqcUnJD2Xl7EiR103eBN8EsVMkmR0AvLeI5XvQ0P1+QZUt+uJ4vwK2vn5aU
9JFr+TJqlLHrU/Ev8Khh+s76/41qtRgvgldWkKNCSjubzge3Dq/75anzr6PtIOvYePH7+NPgTBxU
IZWs3BE1nJuNJeFuAAMRQxP0MAYUFB4KCncGHlYWJq5eaxbZdCIk980ZQZAqSX/20D5EHPEd1Sko
dwUWca0FmFi03+VU0WhoW6xRC6afYlK0hqK/tmBZGe/Pg8kc0/sxcld7vSACLfJAHf7DQea4lTuW
cRK1SPrrGII29g+WXJlBB6YFrHu+lXlgp9nUR92FkECYPhvLxaE9tTY2k+yQeuTHWqo6nt8jORqb
FISmXxd7S9dSepTO79pXcf00eh7At3goAjJe9K3pcUDiAvRyj97PALiBcVer1D6aDIbRzuJW+bO3
VURuBtAMPB9QCJg8neZt91BNQb49cl1oRiVKkdFygyxaGoawRWI1f+pXwJZ3oiC+Y7d3YBt866Hv
ZwzKjm4TWPfAvIJOgOXmCh+62jlQiPbliAuBXNNvxPRR2ANdQjZcxVkUZjLO+0uwJE1eDPWukbln
e23yUlA/kx8eOw4Wx8G0JuZfgpkpAZuepFxO1vEwPo/nzZTF1S7ay1RY/LC+LKTNEFLqD+kcpw1+
2/ILZMrTyKV6qtOzL/kKocIOxMn6e+w6aLZscli5f9xFJeTMrkr/pXL01VAQ+SuAniOinkULLBWQ
XVwDxhBrtu4aP299P/N2FntR6crscp1OU8ATQlu0ZZLn5AsSEo1frxvBvALFwA+p1GF9nEjYzkG4
e0S9KKm0pIQiwrgXg//yAAAMjUO3xERDoLMysfRdGhlSY7tBM3KZqSGNefGEM9PZp5XYSULDuJX9
H32ZKhzV/Ln21OFAkVhjQrbvw3/KJ4NXO8d5Uk0OlS84bK4jvmBUYM/QqYi7BWNcOUKRla40A/tL
DwiJS38Ft45h3YtfzZ7nn4yz02mMQ/e/HYVhSaiDM7+jIPueewwjsqGSROdnSugufREjuvrjWkUf
Xg5TcjYaqZArQs1ewsy0liur6Uv99lLGr0zb0f14+ikk8lDCwWGqAcXN/TLC92Dvl0XycvrEUrNn
dlRGQwhBc27mRj82x1hi6bdPbAlS/fNNqfJXjlQXeEkveFpVqTHv7XS7CbkeeL2eb0Pa0U4Addlv
oQJDiZAwpPa58FQJ1oKzoYHLgCWsXBca8eqYDQQfqNkoNduXjObmyEyV1DdAjO1VJaxhuQlln3ZH
0DlNBPQ9weFW4uz1nk7QNXyA6hJegvSHP9kddroR2gE1XDuOGFBNzChLAAFpeK2OD+lYArFXzxX8
YsLgd4l2oJp3+fWN/dR857C9x2jqdx/3XRHpcN7UUnbEQ73PEDHyRPlfpHTdY+MZ51ma4rn5IQ0N
LMa4LUKmRECkVaXnuF+XXXyDF8LZYZca+4lT0iAUhg0bU1yc1KJ52Ze1G1P0duDMUZouBkNDFZ73
NGnEpCbYhH6fn8t2HmwX7r5RlpfdpQ2OFuDnRaM4guoiZd+IcWbvux893rfYf37Gi584vslaEHBY
VSYYV8iR3lJXnqTjegQwI4z/9faVzgBIqNMUnRoAhSAs2bmcJKeeAsDOFkGqU0uqYWgBByDJni3K
3S4dUDRryomX2EO6s9jn1DrsZdWbXG60OAqRcewEAGLUi+Dc5NJSFsjHArvS9VYTn3dKZ4eamKgK
lEkrtgHEA2qcQ051XrK3W84CetGGTn3lyOAL8noqpRBsejmX09gIRbvcAzpRy8h1u17vL6i9/URV
Y3GZ2n7TSugghGlk+ZMHX858jWsRx/1v1dUJt/5uer4VoA2AymQCSUMzMKnCz3Lz+boKNp4/Qbgi
I9ZJFU8OLkcKJKcFBBSpjld1qAtUHbBvi31vIAw1oq3WCHckVik3qjGmv9WboR4gar7qS/qUhksI
E1SsDVC9jvo+jplXozwBZQcQI1q693aUpvw1ickN3BC1kDSnVHqKRwpHhVSjtUCkX+k3sbg+08Dp
JKg9cI2d01atMpI8zKvHpslLfrUiYuegaoWB6P30lmen6C5ww4dsm302DVPXXwmYC/ayNz6Aj3hF
djUCnCAFLXC97AOkcrBZYq78ItmuzHQqKvUFkcqBc4fBtuzoVdWWfNZ7nosxNF3E+lbYV759hf2B
A0DQDGuRXXAXu73w3BmVDOTo15AfPkU8U3fq7rF5Dc8Hl3fPNaq4jAS2vpVq53mk/1YZM7lVjpKG
xGzr1M8CJxO1x+n+szPZmzcap+wgTpsSzQupCf+2v/to0IJWsJ2Li1KiBJsW6ACrANxpsCL4AVfC
g6jZwwcDMQolCmqVoLdqCWi8ApSg+ZZsv4dbLKwPPT4y3lfe71qWBZqM2Oc7+md8w7nz5alPKsZs
j6c/jBYWKlmAt39xHBIcYkr6IOlLJglAbes4Hdq62ehOQVDsJbYYdQ2qCbEsoIjVLIKiQpkcgklO
Hj2qt8Rg0rNBkvw7Xo+j9FDh4xaLcC3sKRfZIabCqomIt/QUfQrwI0u4uY7ppJ9NfIWgtfBtQ3N/
Q6UcsA5I8Doqxahv9sOM8fYbZk8rjKw/eN/zNcJvqbFXNEEBTqyJvTRsptJtJ2qDdiArv9ej2p4Q
ibtpa+Ok+5otsa0mMSsuUB+JH5aubmgjEomu7fPuH7HWQxNttsR66gkih2F8poVLOOjqsyYuNdxn
Nk5nzsYC8YWjzCBjqn5TAq2cDyWGaCvR/1aeCpJro5+Lou/4N8rPjwEq6vRnODsxS4Tw/ImvfpSk
/REM3AWZ8HWjyp+p1xtR1exkBTKTdPIwmCIB1Z45yQABNgN5XUc0/s6I/OVcBxGV6xr06Jefjgnm
fkb8Mx5omKHd6xqa98d5/2Ywz2bODQ5Nz/wcAMjIsegW9pfi59VaAGVrkhHeXPJ7CJGmZEJlwM8t
TsiaQwtwYGwXdFAOt9XLD4H1GkTJRkWgCNPczHFpBDHHI3f1Lm17oXtlO8PnwZI6Z9C5/lNbet7Z
xTfXrp6mFX7MOUdprYRMzTCq/dMacLEOtbvy15nujd7Ipv0u13tV1HDwTHuXyIu1WOnUA4ZjcFWB
TfE7n19W9YWF1ZIKKMJ9cxiiV06d64cA0grMYZfHf3hBdl8HZN4joj/w62diGV87uk1drMOtP08g
wG3I4zAVTra26G50YxL2/r6g3zXSAIL8euBdtWhPKXOXzwi4cpjwz3xaswSx9mA+YOfvvOm/FEzp
MBsW4yLiR3IBcPP7eB7XxpXYiBR53QNTLyGdvqgaMCXrsE5t2wkOnJxh1JxbmI9kFh5u3S6rF/Fs
KYOg4uI2LuDjWtBnxQ+l8YPXMimkpMNPJ1//8SgSk+hhYSzAjRBAssR8h87k3orjwPzuZK5QLnk5
f7QR6jEwhbLlzK1BvDT93rqQeP5TAusufcYbCO+gTlbjdvv6+869SDB0TjSxnZ2ZL9Wxtw5a8y4r
v5Guf4ny80Ui1wVprczu2ONU9buRRHiyy6K5MgC9qVGK8PgWIJzt1utTx7fkNRAyEBV/L/MhWZoi
+CKfUNghgu8S32EVqIad3L5wWfNq1g4VWAVPIfB2Hxgv7LgJn/XqvxttOCWmGHsnOz/qT1VNQ3Za
Xy5O+j48REwazocA1mbKmOHhHHp7GWGgBSA5Glq5j6y/RoOXcKOTu4+d+nLtqd9FLXkr9S9qXtpw
OKjeQeLOeLxvQNX52XQeSnRGOZx1TpYjJ4L9/Yv1B48iJRJAymq86HZjFcWCQR1fdI3s2jnv6duV
N0jhY+n8eGTlyuarrlXroTdxh1hZIJEwtN9tjhh0V1qBKTQEWDb/s4U/grm5pyk6DaHfWuDHyO+q
en5kTZffvmThUfjt87e180Doap99WR4y4NJwiRqVe9JEGF5qhJHSXi3RXhjhNnpQa/jUv4qIi2BP
vCbUh5LSVSTmp40OD2Xt4EpBjFqUWp8ck2iTk0WjBNt6AD4t4fQMbA6az+/ayDk8wVPi0FPx8MZd
5mqQgHrdmujgQXHHv+8A/rANrHtepEMJWQiABqfPHvz7+TAhNwW9HXZuyxMwqIh08lb6i3u57uii
ohyNvf6A1lY6x6xFax2LeKyJ8RTPusKPGVaexFm6T7xwq8De4lNkF+xDTcWW9knnzB4A035/O8hf
/zSGrG3pFDOqOjnvGxFNN7U0uDI/b/ZxMmOKP+Lyr7Sq+bfjtGabs8qwKCmKq1M8XXNUbN05b9WM
LHc0xQvKaOtwm4iaCG+z21+K5TOk1YFujF9WCYNpXvoU4pHCBLExbmV3cwIAAADwDQAAQukNg/b1
n6VsWWGsh2lio/VfzU291RH9CLllJgeC93znUeG3g/3I8HOaOb00hHODuTD+W2nxmfmiL/oBMVRq
kF9+N3P9EVrYWH4Qblj2nSErWawwlEdtlG6tmbiCFG8UU4teGB0/2vuZF+g6lq+V6T3+qm0WVH+c
oPermZiB++9QLbFp9t0n81IUvAcpHdxe7JPRwwAK/276+IxDaDwMqG1qvVSroF6AOGEs0sKTT69/
Tx8EInYcLZpMAmFhPC3NPSTWCTwBAcT/3EFk0mDVq9GI/gdBa9ileN33eJCvJXnjX/mEhRfsVu/R
eFZk6vwIQaRdZ3FoKS6yTju8XqPVrVvUChQc3v6mBE/N/tEQW607x0f0+sQWx7MoKvMviPlQGqF/
mD79yD62xIFs0GdfPopUO7YiUfIOarXwEndEKJI9xYK+NuHeMI4yPiBwZiybpW7e7WnattpR+Z0N
4K97zwgXlOevE38Ktwgcz+bV2jqIeyhUQ4FsGOKWFt3Yapf6rYkwAFP5PhmWZTz9CNU/cQwSh6ry
wL4yeKF4cbIXFOO4Jv7oOZL9+otKPI/9djjWJhyCFkF+1Fs/S71iU7xz5OfoVvPg01A2gof/3+Bl
W0LeKdhi1IMye3CCwDIOV2y3QtO1QP5pfXzFNBr0FhcwcSbhy6DcghdWs8OrQhSgmQdBm4KUoNE3
cfI9cpBvgTSZbHIGD/LAjbezkX9tB68/LR752sDgkrAJkGUgkY1RDv2LjgIk85SxaeY8SWS10glV
8Tx3hecUmNtcnBJnrgSu72NF9/PyXwHNJPlhASteN9oRiHbS89UcI287ywc54eRF9FiLk4cUKCer
u2Sa9ex48pWxYBcH3CZFlXmUuyAhxtQ+4SeMqmKwsclS8QuapE5s36asHcWh39WZm2fKyOsOEHFz
MoTQzmmThleY7ugxxkd4ntLQ18mLirv1LoJ5gIAVZtPhmesJkZl/zdxUUlixutaQ7iOSVsGF0Orl
o4TYM6EV25TunhFKvwS12dBb+P0NUeMzcDnFW3WKK1pVsTwXxDvLkSYjtRS+p94QbE+6WxA16eMi
0Bvm4CX1OUOrSyiF0ftXxgAPhi4Byr+mHQIeU8D+qDayOId7OiZyUb64sKIq9keIlHI1CCZpPlw2
O37gzImQlPg7xqel5sIAuExyHHJmFAnEHbgs6/VvMvAN1NCvN3wj0AGv4UyqWIxz+VsxuB81oOVQ
7MlsLi7M69oXOVl/+P5HXWS7s0zgFq6PoY1CUdTyXDFCSOqo6+TpZz2fNKr/mQ+E94TE3A3NfAMn
4YD+Vl6kDKYjEbaNUyi2bZe4u+I59iavQhNVZM9ilaIWG0xpff1mYZ3Fn3iPIoRgUMJNwwgpe32V
u4cVrzWccVtnuUc5iqgMz1JXxKvFqTc8LvLi+0FXkEY6uMGa0+VYAC15B35rOa9TACW7nlyn/VPB
pHUxdNEJkJzpDgCukTZj75QlGn0V4foe6b5QTpXlFSVtoXXVWy8Cch9Tdapwt5zN+TE0/5QkaEEM
/ar93OmS/nkrfU0MfoQIJEsywC2QnzLLam49GZFXOSOebGasscjNl5DhqFawM+5J/btj+tl6KO5c
+4lUBJef6nDNNC5d9pc/SCpZEDhqXXcMKnG3WqeAwNwqmDjTVrVCuAm3MerEilQcQA6aAq9ZvAUV
lUsdj0PU8NlfHoju/YrgBR6NEwmtUQNZ6NxO8gGVY3LUaZ9+NBB3ztsYhD8xvMyx8arXK3KqdyMx
ySqBxxr0gutOnAxodHRwAgAAADAFAACEeaKGI2ei2X/f+8N8r7rCh4G5vEl4tgCcFq8qR+qAkV3J
oPhdbSkpxrBirxkrJHGLFFB3ym3eHJzSaz7OdaJ+oaYJSGtYE4YxjADa4nqIN4MHFn6+Ve1BbMRV
sG9S4QeQs/CX/hqDl9CM7FWOcRIeo6I6Qly5k7OinCR8XUz46godIPJFyn0JCIYwxbIaqzTYGtsO
h86UTsTex9SdNoXuFjjd8NwEjoktRg44o6xMH4hGYAYdhK1JRVx59A7Ve87XosPHYARqBK5tCs+w
03b+x4Xl+zFTsaP5Vbc4jqJgxjanuTrtB18oqk5FlBRZ7bxCVpJ+0dl0LN37eiO7khkr5dd/wftc
uu6JrmWll/5ueAeijY9cbDxw22U4l5Bzrc+kgOMBFb46rVyQHULGNVGKamX/2KdXM8wHa64cnmPk
vPGMYd/DOC2Rtd3GTzvyPxgp6oPcxNetkUIoaRamCgtPG80SejSfGU0zVM/WAQcQN0mbF5WvhthB
2w5u7wLpo6NcH2YJuCUcmwt1GLXDhSYcYXZpcAEAAACQAQAAOdBVKZPIpN5O7z6anTcLrfp3i81F
3E+JV+qTuHisSt6ju4KiokJBVhV2waqz5345uI2SZw4CLGdtB3ZNwcH8oaEwbUk00XYSMR7LE32O
I4rKsPXu/O+obYA1oxB9e72oSMxeJT5O1WYgvDLoKlJhhI2WF/+uGX2D8D1Ixd+q9o42VAx5SxsM
eCM1QRGkliT6QhHRgRRiT/brUjPI90mZpmxSq7dkEbS7Ipigfv0dMx8UKZdm6cAErub/1FdGWTdO
WzkoGstH4hM0/C0k1zqXHCmEp2k/7bZ+gUccpYN6h8krOJeFMx2j8Q+sYyQotrII2omMKvinNQ+Q
25kbP2R1bMeCOQIZuwwSDOUBQLIwPBPys98KDQLJZ75N8+DYMlRaP/1fubM2p0tlufbECVhBb2Uk
DwUzK6h3WXgOFdxtMKbD7hj+a2+rFjzoQ+pbMLA/MKzkL3KaSINNHW/Io/r5R9Vyx7LYKG1teNK5
e4tLaowSvl/ZUv1O+JVY3qeW+8sfv8CGV+bQoz/PjabuupygiOayoCBToMsAQ2t7Kw4niDy2wd5Z
PVgiTxbQ5lJKc0kOV7oI7v8w+/TLOTp1lHpKtaYL7rLDijLFV05Hg/Q9PB0x93xASqRLtmsR2MTE
TU/yeMgawYzwm9ghxfAXErO0pVvHpwHtb+7WqhT27MnePpWvhIPOwdQx4m7JGQ3rlDIo4az2bk0t
1Ayj3NpmNeSK9746Bhs8qaWB2BecAadDLxxNisBnTbQkQjr8XRsjR7wSGs8AfYVjperrdH9WlUCo
q32XQkH1HXWHr8hucNtQRT11X3TLrDWlqBS8dMuBtWHSRLiP513a/xQIz5/tLp7quoPNWzSQY7GI
i8SkDbs5pUXz0tjo9sOpAQoO3+WAsuzcR9FT5PoeB910MfKxGKEq/ehDLeXoL7P8HUj4gpffwr2t
E+ppW+jnguDljmgwYr11nhqzlPZaZWmPgPNMDwNmgZ4v/cBhwMh4Oq3BOtDi3nBAxvjBjZ+8C5fC
Ffd+QMzpFlVdWdlQ3hxKr1y25EZyegg/SkNjHIGNMNfRHYGQI9Iu6i8obk/p+muGk5+cQbNN8516
6uimBdWqj2YZ6SWwLF3sGhs9gFvQOnWvYNmu11a3nUsrRRmRv2dGM8/fvBGKUm5SqFT4i8QuujOv
3nETkah3utq4gnbN9MgsUQf+EQ5vB4Qj1WwxHmi+UpNnHpNxLr0dgEab2TXdgL9L/FytM9SvSG4g
YGCwbM7shzZChoUJ9+1ep7eOjQgJKrYYxsIB4+9qNCkxEt+DdccF5GZBFJj5saQRhszrMKBXjlZG
tV03y9uru8qLIbeR5DdF04Lfut4IhevUQXoABkVxWla3OVpR2SCMtGGCaK88K6nUlcixv2UZ1e04
hYSK5rMxd5ndQ+eQjjj2kCDgPWQnpHXtD9kMDtCMqCDjVZTG4T5Rx9XiVHTLCsPByyXsY4ojjA+s
SfHHKigUep/7q/p7fjUAOf6VXMLsApphB5JEiv0njLMru9Z3JtaOIiHentVv1wiDc8HxpoKypAMh
lsLXcL+rPokPMDaq2+YG03G14tOKRE3hS1pfyfi0ba3IV8pTHZu0fxfvsG8dprWj9KIZ4bhaAKN6
UF79rz+wDlZmhjV/bsAlgBLR4xTEIth8wqSH/yRIKcCMd8pX/aFkitRG0SSzgQz1CaT2Zt9fpaoh
t6KWWjawlLs+jR65bmCQ3zxq+HLXF3AFdTeTtAYFeL/olVK5gmSfc0WKkw01FoIbVVuQHfDvUiGg
8pxfVdXvPnGzQbuY0tZNcbQz2531yHVPGGpUNXmhlXPMjEXp1BMegD/4KRiAVbHqvbFVvu7qi4y7
b6qqgKLOgxhqD2dvHky+R0Uf0H2gEwseBwMK2+q5e+VT0mj2Lrg5UB5cIIrP6qvrBa0poCWgwxYd
NqaEOySGcs42XNORIpYHy95VE1XYuzUcEaQ7oc7zws0BvtszhRxD6m6feJuWomG4PIBQKZBx4zTr
x95w18FR7asw1cJWWoFZTOos5TQTxTIOvgw33hr458cEEJ8IH1DEfzeydoRFHpcITOZG1pdV6Dte
S+czUb3EDyV8RFPasDanHK87q3poDKGuPH46bxbVlk7rcHY/4Z84bdLFd6UUdQ9zy/g4kVpRb+gM
pBNnZqmWLwsZtQcw9ZsqJfC386327GyOS57Ej5aVgp2iW/OORbTdY4MgUk+SW5j8n8WSbbTltpbC
1nyr73wlud1trwxJ+MaVZpVcizvl/lcq4yMi1wtz62/YJrGj4mnsjvAq/niVMeGnRhcQrYP/hXF+
d0Ln/AZw4nvVzEcOcmRFlmlTBPfbKS5xuONZypre/weTWxJfu0dqyDFAmkMlswKW9ci2YgFGewqu
gqQgUCrktNJ2Wf7utSlE2rjzy5DXHqzQhAC1TkTNQ5wev2gwBe/+Z6HjQnr0X/9n1oLmcgOdEMNr
AfYxs4Yk1w2xst5k2MmNj6O/SP6AxS8Wqjl9KSah07301JZDgVs6zwaNvMx0Qnn+rm7Y9KWNoPEm
3hLn0QoSLpbllpXMgnp4SfXzOMv5iyrWWIZWaa2kwuzm7sYFlE5HrKgbojvNF8tGSjw6UsUOxoHx
MqYoTeFof9dWA4T3+2BBClEO1lE5YGS2rB8boDpTW/X2s1NXggiNCRWWQHrAWToTkh75QZZE9Iup
tu/BvnU1nBP2loQvQkNWsgKKi5/i03q/qZGBgR7llXuROBbRzYM9bzr1XKrUPL1kiJv51CVZYpIi
5ig2A0BKCu0xnVSsiU/vbdsqPBpHKwcPKjbFsdDL2Ky2btEWAo7sWJP9lp6FyfCQSDq7inos7NUX
tSkoVW8ozprv5N7NLpBgph6qJ8pDeDRd7RMR+25GdGV4dAIAAABwCAAAxjTRoxMoNZq2b2dmVZGI
feRlU3qUG/aC+vp+shDvpebe1NYMy0GWTeY2vhUeCnMBQBefcvtxt6ZjZKEDoCdcPYr0ZZ6VYFMV
rsfchdOByZkIbZPJpmUCFoPk7/OFANyfQiwEmg2QmsmMXQOQPWnge2nMOKx2PvYMhQBBNH0NH0OR
TTKzk6vS754kC9SnZ/b1MAirvGMSfQLpPYwOSp9jU+h2sFA6tOpOTp/Sw/ynYhXfb4qYhuvvaxB3
DC/loG+4CJWkky1P7ATMGa705hFlTqrMW1+Hy+ymIjLwQMTHM+3VvQNUN4scBn5GJ2Q64UkdxJFo
ff83k4dGhz7FN3x2XBrhgCRNIr3fiNvfUN6JezImjTZsGm4S1oFrex0vPg3E1Ru1kfDHwDTtlmQP
aC+JNTM0VhGoUjJrV+4+7GPYbRpcDGuD554k8yJopj//Nm9kpjhLCWXVyovr4eSBxWmnyJZAbIL6
TifqRNj3vg+C630RgWWulCqq7KkjUCCPU3m1LDuFe6v7qiHBfOUPRwoy9oeqh1aZpOmZlvmg4Ysu
AO8R1CT2pcW06WjpUhPwlMl5qUj3h97YWgDyzeyu0jCSq1o9BtEaG1QYBjp/ZTE137JtmtYyc1e1
kFAmvjajQehbylHvRxGTH9iIpdwB53/xJRvcYr5jvWZxZeUB3ELnwpSzzsjvGz+UvG67a+/lia8O
wCMh/2KTTBsqIvyu6/SeqjDZ+A61UV+8gglppY87euJn1qQgTujS62RvDNVAxV1R18WVVWVZD+0U
5DXoMF7u3koM1OJYDGDYQ2vwdV6poHsGzxLo35cTLq/jsWpmh7Hep6PcQruwDf/ICU1aYhA3nTXh
+7j+spwNbz7/KrNiJjuiD1Pvhjx3ZKSl9kZdPY6r6QJDLVBsc77pjYdgxd+GPlhsI5DwQdGa1Lo4
CdAEoKTf+eu10DD2wafpNi3B7YO64mFi77NUjsQCo18byNoZq0N7oM/6/UX26Aam/rnTJeCgVI4Z
u+8vUBgH0VOyFkGbHYGvFAFRnKKc38PRrVD+SaFEmfqmqLkkICmxx0JvtNMQFeihwek2HCn5KaDH
+ZHbgM1rm1m0lTNxQd7EDMQNWD8s3j5+G7nFXbKgWYWsck2CMPKbgZ0x042/Y7VfWMhgUtyaAS8d
Y1wJtTAXpMo3fybsy/YU8KKQnoAiTbP27AF6C+DlTOb6tekyvUl7+14fScegoWuDslXYkz9QDPdV
1qD64ZLlEC21G9ey3Fb3uCZU8U+zzFdULaOFLZabFlFS90bMIp+eqKrTSGYTsd4hoG5GJdlUa1Fq
ODHEsHxEfWMh9JKuAyLEidN7PNz6fTJHbFUEhqHZzXncOU3EZ+KUb9UJJF0CP4chyUSpa59EX2fN
yiWqaTtMd3Ez3ucNChURl+rhDIJU8PJFwbmcHbwXqa5mGCmdGPw4h3GmzzHMX4HtSXpMICzScprp
9EUP2c8y7fdjTGHBH1E+6YXPM9dVb3mTx3C236vArH5Kb9bQ8IC8UrP0mThBoISnGrqVA7wwCGuh
75ps83KkEHXI+TxhEmN7kjGMN+pFRlQVTwG4G9OxP71KUaArZvKiMXpHyPPl3DSYzrlGegeIkqip
YxcSh4BiY9PMTRF/S+cn90Ufmm0uW5D7bDaZxGTXOeKBRjIrgI1jwESVIq5ebwKZKsfqD274al/5
/vDNPURNP2Hu/fyAulOEwXwTmRnb2tvEwNl1XPveW3AOdtsQ8Y8GzLbB4dV6edWLEFzbVScGNALl
LBsjW30sg1jjI1Wesa4gRKsIjZ6UqtKkbphQHK9wkn8MKmx7VG9OBlOu/qoB3gwoJRu/j8v4AK5f
jS3UY2ixdIufH6CcbAdALJFYj10ESXsZk9cLw6q8f0JdHKGeHoFLeuoW57blLMqbqUKJlesb7Bz7
APph7zxWETJOM2F3LFloDkjViFRZ6KcXl8JYvBgoa4mKUd9XAzXoQsr7FnUS+X48EZBMUa5opSBI
Z+OGtZFZ4MGAkwn7y5jp1SG+EMGUVGgmGOGDYgznyxO5zSXgYjCkKKZFVxAhp56BCgdv3s+rH+8r
wTT/Mteqgw8Ws7RVMHdtuMDXTPgfP7ba8oDtbIZI3qK7MbqScxQwTewl9fKhdeR8rJXZ4dlKxjTM
Tna9zLsQP4NkAbenpUZN/nK3gbufS0gI3XzDDrNsaZHYj6POjszeI5iYKOxes52Sh0N1lW4iPsDP
SrKPByN6Er8HgFbFtYvRHzblL/j0aUl7bTunKlZCysMeanOF5Yv4okEwDx8QcGbd2zhPciTWxkmx
F/Fj9X37bIykpuDrnQjl7slm5xX/9ZOupm72tAAM7GXv2K75eJoYe9WTqvURfXAuT9KQUzwb84FG
s/zvMM3NuABTeR2xORaxwEzWi6gY+FejJib+AtMMX5BZJEJI3QthQcdDiAg7aU9Eyh80bx/zGjia
VGddjuOBADmkZgR2cd3m2tR5WPOq9s9KjSGz6Pqp486KvqV0JNaMzvapvgl6gyaz7egSTGARXpYe
LjZEIOEQWAJ/QF+HbXQgWfwbJUuUVkvsm2wVH5q+CAFDrMXhcW3eZJPCmXvgbxaSMoHrrGaaW4gw
9W4O8vnuE1OWDD2/+RPx9nZriZ27Gsak6EBWQuEraSBky55dKRVWVcEL5MsJzRbP+Tn+aRhqV9OK
MhWxCnz4E/7MTMRCIUN08KcOeXdFGVEawaiglgvj6kreGjjMzT9GUgIXCveU3DtFSWOGsYMc051B
O/pQHoqdUvyE2nvFM8V7VzvHNPcq2NpxJUhLaKsQ++49TybzFfDwWVwno8NJnXOv6Lf83Qke3bLP
SvHtt3+tGM3fQ8g45bQzc0p96vNyLQjAUZK/wL99zbZpIcbxJSOGqL91jedx40gtpF6wMwnORtO1
QelS34Fwu/trZBL+AtMMX5BZJIIPBa+GnvY6Wo2v18mTC+Puz5a8kNxreu9WKd8uecdj84goZGzT
bHSwY2i5IIkJta1MpH6P5DliMyOsQOaJBXgGAFkfNoIpQ5uL38hv3NOyxnjBxCZT8vDNkUxaXu0d
XhCVOnSf5OZ7BBSaqI9HepZVPeYE8x/iUXfILKetrkwvPA7U9GOx3bPj9YUAfWUN8Vmen2DrgMkk
oDxq+eWYPsDKdo1zNo3WTorPga3ukGif/8dELmI8YWX1m5r9rexucGUR9OjiaDYlPHuXEPxz9gjC
YiCQVwvsjBiw0+7jTziHpKiRpCwM+14ylOeMhl2YeEX+NDdgvWWF75oZdBGaQxdhZgA8KznNif9R
PzWrDK4ymaC5cZca/WebbeaZ+daglRly5MmUYvjbjVetnG709OS3f/K0bNCW3nsXQLJkqsGOw8Ni
M2Y1cniuvgyhAAVw5Hj1v/GWWa3pFWCRBxnzv2WeUiBlmHTP7gkVUlD5nFfKU6XhE1uywEAibr4k
IPEk3zKHlGCuO8mkfPFz8Od6IfDcTB8DF6or/3FoGDDESa8/RUwCh1MSWq0iDK9iKVkkt67la6nb
iLp7zNsYG8v7qYkX7ujgnXLV1eER87qIzjpjgdiCLk6lCuU4Q0L3owjbqQ7B4sss8Ksz4qGgVkj+
KaH2r8c0z1t4hVT61MBPm1EH25QaT+jW/jppX3J6AQEAAKAKAACxnB/x7FBeWZecADqOHa4/Kiv0
sexuvMmQ64grzV54Cr+H/HywCSEdkIm40pvY6Nq3vgucfuCtLIXAFsfKrNx9cg9qEWxL990BZsKw
e4lsF/3sOH6JTOc2XDFjnPuRqkcXRU5HlezW+q+zeSXalTQWveC9Yf7xmwv0O8iA4RilwPGLtL1F
E4QlDU+zGGEE6WeZUyBrgyOX9Nbf1bMQ3pA9UUbIZyrCrBBpIPoEeiZ+BI27Za7mQ/LvldJ/3KJf
cHCc7x4oSGCHQGWGpm07h6gb6fJVq+px5ILc2k26oB+x3X19ZTAAmZ5Oo6jQIGwfMr6JkzYQdBfW
f6PR33dcSqPsB4bcSfGge9948ihlNt175tXwzIzO1DD5kM6OiRr20ryeIxVe5j/wsFY3+ilJtTqu
yKyNmo/Yh/Dv8sZLl24Uz9/THu0qrodasG9/PXB2OVEyMSswKLlzyAKAJ513m0vB+/YE91TmNayS
VwviGtGWH1Q2sIShvh45X94ISzcMALZak9ws6U+o/9PQvaMQtyjHx/FvfopyS8DlSEV4t2CUFn2p
XRGuaHOumJnHq7l3JnzR3NXbgZ2hZMelopPIYXPZoffBkVaTitcokrIc2ofMd2Wvn7TyJbL+pnWf
ED9J+EA8PMryZrkhIi4FBOtojxxo6Rqcx44+F7m01hQgEWE3+/RVRfICgWLDezP0Wa268cjUae/T
mE8d6qLASaSQTfZFidn/a25uKtalUsGLmIz0pkV68Hlasw2yeZ88dsFXFlBjo12Hr6sXphJFUduo
FlMrUcZIGVgln+Au6nIwrLEclBQvXyx2EVeUr3jH3xpQrUihEObcsT2CP/i7CzPz9q4XH64YUlms
NasRKcYMOm0tWn4o4PJ+01XroNuU35jZfG2Q+nwnznOoTcsbC2C5TdKVfqSEspnCKi7qOUNmdoY3
YAihm32TRu4290bK/vcf4yo1XnQLfkHBEZhgjyX8fY+YCbuRdflvsJZql5cjW/coBQC9AZlRUPxc
/DSXvJhpe6lNcjnKKlT7wqxINfehnYqDvbJ5O29T0mxyXF6H1gmbs1LmrTLZmLcF96nMDf47NUZz
ZXJ2AgAAADADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAADhwAAAAAAAAMHAAAAAAAAAAAAAATHAAAABwAAAAAAAAAAAAAAAAAAAAAAAA
AAAAADhwAAAAAAAAEQFHZXRNb2R1bGVIYW5kbGVBAABLRVJORUwzMi5kbGwAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA

----VEKTA7C5E70P--



Received: by above.proper.com (8.9.3/8.9.3) id PAA07322 for ietf-smime-bks; Mon, 26 Mar 2001 15:38:10 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA07315 for <[e-mail]>; Mon, 26 Mar 2001 15:38:09 -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 SAA20677; Mon, 26 Mar 2001 18:37: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-01.txt
Date: Mon, 26 Mar 2001 18:37: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 Advanced Encryption Algorithm in CMS
	Author(s)	: J. Schaad, R. Housley
	Filename	: draft-ietf-smime-aes-alg-01.txt
	Pages		: 11
	Date		: 23-Mar-01
	
This document specifies how to incorporate the Advanced Encryption
Standard (AES) algorithm [AES] and RSAES-OAEP key transport method of
key management into the S/MIME Cryptographic Message Syntax [CMS] as
additional algorithms.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-aes-alg-01.txt

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-01.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-01.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-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-aes-alg-01.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.9.3/8.9.3) id EAA15446 for ietf-smime-bks; Mon, 26 Mar 2001 04:19:55 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA15213; Mon, 26 Mar 2001 04:19:12 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA23410; Mon, 26 Mar 2001 14:18:17 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id OAA17830; Mon, 26 Mar 2001 14:18:34 +0200
Message-ID: <[e-mail]>
Date: Mon, 26 Mar 2001 14:18:57 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: pkix <[e-mail]>, S-MIME / IETF <[e-mail]>
Subject: ETSI ESI call on Policy requirements for TSAs
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id EAA15215
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>

Policy requirements for Time-Stamping Authorities

The ETSI ESI working group (European Telecommunications Standards Institute,
Electronic Signature and Infrastructure working group) is working on a
standard addressing functional and quality requirements for Time-Stamping
Authorities to form the basis of a generic time-stamping policy.  This work
item is being carried out within the overall framework of the European
Electronic Signature Standardization Initiative (EESSI).

The initial focus of this standard is in support of qualified electronic
signatures (i.e. in line with article 5.1 of the European Directive on a
community framework for electronic signatures) but may be applied to any
application requiring trusted time-stamps of equivalent quality.

The aim of this document is to provide policy requirements equivalent to
those for CA issuing qualified certificates as defined in TS 101 456 
(see below for web site), but targeted at Time-Stamping Authorities.

International, European and national communities, authorities, associations,
standardization bodies, vendors, service providers, users are requested to
provide any information that is relevant to this activity to the editor
for this area of standardization (see below).  

In particular, ETSI ESI requests input on:

· Views on minimum essential requirements, for time-stamping services to
  provide a level of quality such as is necessary in support of legally
  recognised electronic signatures,

· Relevant documents and specifications (draft or approved) - 
  preferably in English

Even if your organization has no specific input to make, indications of
interest in this activity would be welcomed.  We can then keep you 
informed of the availability of drafts for comment.

Response is requested by end April 2001. However, if meeting schedules 
do not make this possible, input at the earliest convenience date 
would be welcomed.

It is planned to produce a first working draft for general review by 
3rd quarter of this year.

Further details, documents, and e-mail list registration on this and 
other activities of ETSI on electronic signature standardization 
(including TS 101 456) may be found on: 
http://www.etsi.org/sec/el-sign.htm

Please send responses to the editor of this document: 
Nick Pope. mailto:[e-mail]

Regards,

Denis


Received: by above.proper.com (8.9.3/8.9.3) id AAA09187 for ietf-smime-bks; Sun, 25 Mar 2001 00:04:26 -0800 (PST)
Received: from sm10.texas.rr.com (sm10.texas.rr.com [24.93.35.222]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA09180 for <[e-mail]>; Sun, 25 Mar 2001 00:04:25 -0800 (PST)
Received: from localhost (cs2773-200.houston.rr.com [24.27.73.200]) by sm10.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f2P81Bbr013083 for <[e-mail]>; Sun, 25 Mar 2001 02:02:33 -0600
Message-Id: <[e-mail]>
X-Sender: [e-mail]
From: "[e-mail]" <[e-mail]>
To: [e-mail]
Date: Sun, 25 Mar 2001 01:59:16 -0600
Subject: Would you like to recieve information on how to register your pet online for free?
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001__18511486_7156.02"
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 Multipart MIME message.

------=_NextPart_000_001__18511486_7156.02
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit


------=_NextPart_000_001__18511486_7156.02
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5VbnRpdGxlZCBEb2N1bWVudDwvdGl0bGU+DQo8bWV0
YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl
dD1pc28tODg1OS0xIj4NCjwvaGVhZD4NCg0KPGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4
dD0iIzAwMDAwMCI+DQo8cD5IZWxsbyE8L3A+DQo8cD5Xb3VsZCB5b3UgbGlrZSB0byBrbm93
IGhvdyB0byByZWdpc3RlciB5b3VyIHBldCBvbmxpbmUgZm9yIGZyZWU/PC9wPg0KPHA+SWYg
eW91IHdvdWxkIGxpa2UgdG8gYmUgcmVtb3ZlZCBmcm9tIGV2ZXIgcmVjZWl2aW5nIGFub3Ro
ZXIgZW1haWwgcGxlYXNlIHR5cGUgDQogIFJFTU9WRSBvbmx5IGluIHRoZSByZXR1cm4gc3Vi
amVjdCBoZWFkZXIuIFdlIHJlc3BlY3QgeW91ciByaWdodCB0byBwcml2YWN5LjwvcD4NCjxw
PklmIHlvdSB3b3VsZCBsaWtlIHRvIHJlY2VpdmUgbW9yZSBpbmZvcm1hdGlvbiBvbiBob3cg
dG8gcmVnaXN0ZXIgeW91ciBwZXQgZm9yIA0KICBmcmVlIGp1c3QgcmVwbHkgdG8gdGhpcyBl
bWFpbCBtZXNzYWdlIHdpdGggUExFQVNFIFNFTkQgSU5GTyBvbmx5IGluIHRoZSBzdWJqZWN0
IA0KICBoZWFkZXIuPC9wPg0KPHA+PC9wPg0KPHA+VGhhbmsgWW91PGJyPg0KPC9wPg0KPC9i
b2R5Pg0KPC9odG1sPg0K

------=_NextPart_000_001__18511486_7156.02--



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA18283 for ietf-smime-bks; Sat, 24 Mar 2001 12:02:31 -0800 (PST)
Received: from ns.nicchu.co.jp ([210.225.38.2]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA18268 for <[e-mail]>; Sat, 24 Mar 2001 12:02:26 -0800 (PST)
Message-Id: <[e-mail]>
Received: from MAIL by ns.nicchu.co.jp via smtpd (for mail.proper.com [208.184.76.45]) with SMTP; 24 Mar 2001 20:06:10 UT
Received: from wall.nicchu.co.jp ([10.0.2.252]) by mail.nicchu.co.jp (Post.Office MTA v3.1.2J release 205-101-J ID# 111-48316U100L2S100J) with SMTP id AAA208; Sun, 25 Mar 2001 05:01:47 +0900
From: "Rexford Harris" <[e-mail]>
Received: from [65.88.230.10] by wall.nicchu.co.jp via smtpd (for MAIL [10.0.2.253]) with SMTP; 24 Mar 2001 20:05:56 UT
Subject: All VIP's
To: <#field0#>
Date: Sat, 24 Mar 2001 10:05:36 -0700
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE Vdiffondi.1712.3
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0"
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>

This is a MIME Message

------=_NextPart_000_007F_01BDF6C7.FABAC1B0
Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0"

------=_NextPart_001_0080_01BDF6C7.FABAC1B0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable




   
   


Dear Candidate,

You were recently selected by The Office of  The Managing Director
for a free listing on The International Executive Guild's CD-ROM=2E

Our researchers gather information from many recognized
sources, including professional associations and societies, trade
organizations, newspaper and magazine publications, web
presence, and referrals from existing members=2E

As a highly respected professional in your field of expertise, we
believe your contributions merit very serious consideration for
inclusion on The International Executive Guild's CD-ROM=2E
To maintain the level of accuracy, we ask you to click on the
web address highlighted below and fill out the brief bit of
information required for inclusion=2E

There is no cost or obligation to be listed on The International
Executive Guild's CD-ROM=2E

Remember, this site is for executives, professionals, &amp; entrepreneurs
only!

Congratulations,
Office of  the Managing Director







If you wish to be removed from our list,
please submit your request
at
the bottom of this email=2E





&nbsp;


 0); // returns false if empty
}

// -->


        
  



  










Registration Form
(US and Canada Only)






Please
fill out this form if you would like to be included in the&nbsp; registry=2E=

For accuracy and publication purposes, please
complete and send this form at the earliest opportunity=2E There is no
charge or obligation to be listed in The&nbsp; Registry=2E









Your
Name





Your
Company





Title





Address





City





State
or Province





Country

USACanada



ZIP/Postal
Code





Day
Time Telephone






Home
Phone


(Not
To Be Published)




Email













TO
HELP US IN CONSIDERING YOUR APPLICATION, PLEASE TELL US A LITTLE ABOUT
YOURSELF=2E=2E=2E









Your
Business



(Financial
Svcs, Banking, Computer Hardware, Software, Professional Svcs, Chemicals,
Apparel, Aerospace, Food, Government, Utility, etc=2E)



Type
of Organization



(Mfg,
Dist/Wholesaler, Retailer, Law Firm,
Investment
Bank, Commercial Bank, University,
Financial
Consultants, Ad Agency, Contractor, Broker, etc=2E)




Your
Business Expertise




(Corp=2EMgmt,
Marketing, Civil Engineering,
Tax
Law, Nuclear Physics, Database Development, Operations, Pathologist,
Mortgage
Banking, etc=2E)



Major
Product Line



(Integrated
Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components,
Snack Foods, etc=2E)





Note: Submitting this form will
be made by email, not by use of&nbsp; www=2E&nbsp; Confirmation of its
delivery
is made by browsing your outgoing mail=2E


Thank
you for filling in this form, we will contact you with more information=2E


List Removal
Click
Here







------=_NextPart_001_0080_01BDF6C7.FABAC1B0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!doctype html public "-//w3c//dtd html 4=2E0 transitional//en">
<html>
<head>
   <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8=
859-1">
   <meta name=3D"GENERATOR" content=3D"Microsoft FrontPage 4=2E0">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFF99" link=3D"#0000EE" vlink=3D"#551A=
8B" alink=3D"#FF0000">
<p>Dear Candidate,<br>
<br>
You were recently selected by The Office of  The Managing Director<br>
for a free listing on The International Executive Guild's CD-ROM=2E<br>
<br>
Our researchers gather information from many recognized<br>
sources, including professional associations and societies, trade<br>
organizations, newspaper and magazine publications, web<br>
presence, and referrals from existing members=2E<br>
<br>
As a highly respected professional in your field of expertise, we<br>
believe your contributions merit very serious consideration for<br>
inclusion on The International Executive Guild's CD-ROM=2E<br>
To maintain the level of accuracy, we ask you to click on the<br>
web address highlighted below and fill out the brief bit of<br>
information required for inclusion=2E<br>
<br>
There is no cost or obligation to be listed on The International<br>
Executive Guild's CD-ROM=2E<br>
<br>
Remember, this site is for executives, professionals, &amp; entrepreneurs<=
br>
only!<br>
<br>
Congratulations,<br>
Office of  the Managing Director<br>
<br>
<br>
<br>
<br>
</p>
<hr width=3D"100%">
<center>
<p><b><i><font color=3D"#000000">If you wish to be removed from our list,
please submit your request</font></i></b>
<br><b><i><font face=3D"Times New  Roman,Times"><font color=3D"#000000">at=

the bottom of this email=2E</font></font></i></b></center>

<hr width=3D"100%">
<table WIDTH=3D"695" >
<caption>
</table>
&nbsp;
<br><script language=3D"JavaScript">

<!--
function validate_form() {
  validity =3D true; // assume valid
  if (!check_empty(document=2Eform=2EName=2Evalue))
        { validity =3D false; alert('Name field is empty!'); }
if (!check_empty(document=2Eform=2ECompany=2Evalue))
        { validity =3D false; alert('Company field is empty!'); }
if (!check_empty(document=2Eform=2EAddress=2Evalue))
        { validity =3D false; alert('Address field is empty!'); }
if (!check_empty(document=2Eform=2ECity=2Evalue))
        { validity =3D false; alert('City field is empty!'); }
if (!check_empty(document=2Eform=2EState=2Evalue))
        { validity =3D false; alert('State field is empty!'); }
if (!check_empty(document=2Eform=2EZip=2Evalue))
        { validity =3D false; alert('Zip Code field is empty!'); }
if (!check_empty(document=2Eform=2Ebusphone=2Evalue))
        { validity =3D false; alert('Day Time Phone field is empty!'); }
if (!check_empty(document=2Eform=2EEmail=2Evalue))
        { validity =3D false; alert('Email field is empty!'); }
    if (validity)
        alert ("Thank you for your registration=2E "
                + "Your form is now being passed to your browser's "
                + "Mail Delivery Sub-System for regular email delivery=2E"=

                + "All email addresses are removed from our sytem"
                + "upon registration=2E  Please click OK to proceed");
  return validity;
}

function check_empty(text) {
  return (text=2Elength > 0); // returns false if empty
}

// -->

</script>
        
  
<!-- CHANGE EMAIL ADDRESS IN ACTION OF FORM -->

<form name=3D"form"
 method=3D"post"
 action=3D"mailto:gkmt6@verizonmail=2Ecom?SUBJECT=3DInternet Form"
 enctype=3D"text/plain"
 onSubmit=3D"return validate_form()">
  <table>

<tr>
<td></td>

<td></td>
</tr>

<tr>
<td VALIGN=3DTOP COLSPAN=3D"2">
<center>
<br><b><font color=3D"#000000"><font size=3D+2>Registration Form</font></f=
ont></b>
<br><b><font color=3D"#000000">(US and Canada Only)</font></b>
<br>
<hr width=3D"100%"></center>
</td>
</tr>

<tr>
<td VALIGN=3DTOP COLSPAN=3D"2"><i><font face=3D"arial,helvetica"><font col=
or=3D"#000000"><font size=3D+0>Please
fill out this form if you would like to be included in the&nbsp; registry=2E=
 For accuracy and publication purposes, please
complete and send this form at the earliest opportunity=2E There is </font=
>no
charge or obligation<font size=3D+0> to be listed in The&nbsp; Registry=2E=
</font></font></font></i>
<br>
<hr width=3D"100%"></td>
</tr>

<tr>
<td VALIGN=3DTOP></td>
</tr>

<tr>
<td ALIGN=3DRIGHT WIDTH=3D"300"><b><font face=3D"arial,helvetica"><font co=
lor=3D"#000000"><font size=3D-1>Your
Name</font></font></font></b></td>

<td ALIGN=3DLEFT WIDTH=3D"300"><input TYPE=3D"TEXT" NAME=3D"Name" VALUE=3D=
"" SIZE=3D"29" MAXLENGTH=3D"60"></td>
</tr>

<tr>
<td ALIGN=3DRIGHT WIDTH=3D"300"><b><font face=3D"arial,helvetica"><font co=
lor=3D"#000000"><font size=3D-1>Your
Company</font></font></font></b></td>

<td ALIGN=3DLEFT WIDTH=3D"300"><input TYPE=3D"TEXT" NAME=3D"Company" VALUE=
=3D"" SIZE=3D"29" MAXLENGTH=3D"60"></td>
</tr>

<tr>
<td ALIGN=3DRIGHT WIDTH=3D"300"><b><font face=3D"arial,helvetica"><font co=
lor=3D"#000000"><font size=3D+0>Title</font></font></font></b></td>

<td ALIGN=3DLEFT WIDTH=3D"300"><input TYPE=3D"TEXT" NAME=3D"Title" VALUE=3D=
"" SIZE=3D"29" MAXLENGTH=3D"60"></td>
</tr>

<tr>
<td ALIGN=3DRIGHT WIDTH=3D"300"><b><font face=3D"arial,helvetica"><font co=
lor=3D"#000000"><font size=3D+0>Address</font></font></font></b></td>

<td ALIGN=3DLEFT WIDTH=3D"300"><input TYPE=3D"TEXT" NAME=3D"Address" VALUE=
=3D"" SIZE=3D"29" MAXLENGTH=3D"60"></td>
</tr>

<tr>
<td ALIGN=3DRIGHT WIDTH=3D"300"><b><font face=3D"arial,helvetica"><font co=
lor=3D"#000000"><font size=3D+0>City</font></font></font></b></td>

<td ALIGN=3DLEFT WIDTH=3D"300"><input TYPE=3D"TEXT" NAME=3D"City" VALUE=3D=
"" SIZE=3D"29" MAXLENGTH=3D"60"></td>
</tr>

<tr>
<td ALIGN=3DRIGHT WIDTH=3D"300"><b><font face=3D"arial,helvetica"><font co=
lor=3D"#000000"><font size=3D-1>State
or Province</font></font></font></b></td>

<td ALIGN=3DLEFT WIDTH=3D"300"><input TYPE=3D"TEXT" NAME=3D"State" VALUE=3D=
"" SIZE=3D"3" MAXLENGTH=3D"60"></td>
</tr>

<tr>
<td ALIGN=3DRIGHT WIDTH=3D"300"><b><font face=3D"arial,helvetica"><font co=
lor=3D"#000000"><font size=3D+0>Country</font></font></font></b></td>

<td ALIGN=3DLEFT WIDTH=3D"300"><select name=3DCountry size=3D1><option 
selected>USA<option>Canada</option></select></td>
</tr>

<tr>
<td ALIGN=3DRIGHT WIDTH=3D"300"><b><font face=3D"arial,helvetica"><font co=
lor=3D"#000000"><font size=3D-1>ZIP/Postal
Code</font></font></font></b></td>

<td ALIGN=3DLEFT VALIGN=3DCENTER WIDTH=3D"300"><input TYPE=3D"TEXT" NAME=3D=
"Zip" VALUE=3D"" SIZE=3D"12" MAXLENGTH=3D"60"></td>
</tr>

<tr>
<td ALIGN=3DRIGHT WIDTH=3D"300"><b><font face=3D"arial,helvetica"><font co=
lor=3D"#000000"><font size=3D-1>Day
Time Telephone</font></font></font></b></td>

<td ALIGN=3DLEFT WIDTH=3D"300"><input TYPE=3D"TEXT" NAME=3D"busphone" VALU=
E=3D"" SIZE=3D"22" MAXLENGTH=3D"60"></td>
</tr>

<tr>
<td>
<div align=3Dright><b><font face=3D"Arial,Helvetica"><font color=3D"#00000=
0"><font size=3D-1>Home
Phone</font></font></font></b></div>
</td>

<td><input TYPE=3D"TEXT" NAME=3D"homephone" VALUE=3D"" SIZE=3D"22" MAXLENG=
TH=3D"60"><b><font color=3D"#000000"><font size=3D-2>(Not
To Be Published)</font></font></b></td>
</tr>

<tr>
<td>
<div align=3Dright><b><font face=3D"Arial,Helvetica"><font color=3D"#00000=
0"><font size=3D+0>Email</font></font></font></b></div>
</td>

<td><input TYPE=3D"TEXT" NAME=3D"Email" VALUE=3D"" SIZE=3D"30" MAXLENGTH=3D=
"60"></td>
</tr>

<tr>
<td></td>

<td></td>
</tr>

<center>
<p>
<hr width=3D"100%"><b><font face=3D"ARIAL,HELVETICA"><font color=3D"#00000=
0"><font size=3D-1>TO
HELP US IN CONSIDERING YOUR APPLICATION, PLEASE TELL US A LITTLE ABOUT
YOURSELF=2E=2E=2E</font></font></font></b>
<br>
<hr width=3D"100%"></center>

<center><table WIDTH=3D"81%" >
<caption>
<center><TBODY>
<br></TBODY></center>

<tr>
<td ALIGN=3DRIGHT VALIGN=3DTOP WIDTH=3D"300"><b><font face=3D"arial,helvet=
ica"><font color=3D"#000000"><font size=3D-1>Your
Business</font></font></font></b></td>

<td>
<div align=3Dright><input TYPE=3D"TEXT" NAME=3D"business" VALUE=3D"" SIZE=3D=
"50" MAXLENGTH=3D"60"></div>
<font face=3D"arial,helvetica"><font color=3D"#000000"><font size=3D-1>(Fi=
nancial
Svcs, Banking, Computer Hardware, Software, Professional Svcs, Chemicals,
Apparel, Aerospace, Food, Government, Utility, etc=2E)</font></font></font=
></td>
</tr>

<tr>
<td ALIGN=3DRIGHT VALIGN=3DTOP WIDTH=3D"300"><b><font face=3D"arial,helvet=
ica"><font color=3D"#000000"><font size=3D-1>Type
of Organization</font></font></font></b></td>

<td>
<div align=3Dright><input TYPE=3D"TEXT" NAME=3D"Orgtype" VALUE=3D"" SIZE=3D=
"50" MAXLENGTH=3D"60"></div>
<font face=3D"arial,helvetica"><font color=3D"#000000"><font size=3D-1>(Mf=
g,
Dist/Wholesaler, Retailer, Law Firm,</font></font></font>
<br><font face=3D"arial,helvetica"><font color=3D"#000000"><font size=3D-1=
>Investment
Bank, Commercial Bank, University,</font></font></font>
<br><font face=3D"arial,helvetica"><font color=3D"#000000"><font size=3D-1=
>Financial
Consultants, Ad Agency, Contractor, Broker, etc=2E)</font></font></font></=
td>
</tr>

<tr>
<td VALIGN=3DTOP WIDTH=3D"300">
<div align=3Dright><b><font face=3D"arial,helvetica"><font color=3D"#00000=
0"><font size=3D-1>Your
Business Expertise</font></font></font></b></div>
</td>

<td>
<div align=3Dright><input TYPE=3D"TEXT" NAME=3D"expertise" VALUE=3D"" SIZE=
=3D"50" MAXLENGTH=3D"60"></div>
<font face=3D"arial,helvetica"><font color=3D"#000000"><font size=3D-1>(Co=
rp=2EMgmt,
Marketing, Civil Engineering,</font></font></font>
<br><font face=3D"arial,helvetica"><font color=3D"#000000"><font size=3D-1=
>Tax
Law, Nuclear Physics, Database Development, Operations, Pathologist, Mortg=
age
Banking, etc=2E)</font></font></font></td>
</tr>

<tr>
<td ALIGN=3DRIGHT VALIGN=3DTOP WIDTH=3D"300"><b><font face=3D"arial,helvet=
ica"><font color=3D"#000000"><font size=3D-1>Major
Product Line</font></font></font></b></td>

<td>
<div align=3Dright><input TYPE=3D"TEXT" NAME=3D"product" VALUE=3D"" SIZE=3D=
"50" MAXLENGTH=3D"60"></div>
<font face=3D"arial,helvetica"><font color=3D"#000000"><font size=3D-1>(In=
tegrated
Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components,
Snack Foods, etc=2E)</font></font></font></td>
</tr>
</table>

<center>
<p><input name=3Dsubmit type=3Dsubmit value=3D" Submit By E-Mail "><input =
name=3Dreset type=3Dreset value=3D" Clear Form ">
<br><b><font color=3D"#000000"><font size=3D-1>Note: Submitting this form =
will
be made by email, not by use of&nbsp; www=2E&nbsp; Confirmation of its del=
ivery
is made by browsing your outgoing mail=2E</font></font></b>
<br>

<hr width=3D"100%"><b><i><font face=3D"arial,helvetica"><font color=3D"#00=
0000"><font size=3D-1>Thank
you for filling in this form, we will contact you with more information=2E=
</font></font></font></i></b>
<br>
<hr width=3D"100%">
<br><b><font size=3D+1>List Removal</font></b>
<br><b><font color=3D"#000000"><font size=3D-1><a href=3D"mailto:zak31m@us=
a=2Enet?subject=3Dremove">Click
Here</a></font></font></b></center>

</form>

</body>


------=_NextPart_001_0080_01BDF6C7.FABAC1B0--

------=_NextPart_000_007F_01BDF6C7.FABAC1B0--





Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id GAA14248 for ietf-smime-bks; Fri, 23 Mar 2001 06:36:16 -0800 (PST)
Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA14239 for <[e-mail]>; Fri, 23 Mar 2001 06:36:14 -0800 (PST)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <Z2A497PJ>; Fri, 23 Mar 2001 09:36:29 -0500
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: SMIME <[e-mail]>, "Stephen Farrell (E-mail)" <[e-mail]>
Subject: RE: certificate and attribute certificate imported from PKIX or X .509
Date: Fri, 23 Mar 2001 09:36:28 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
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>

Sean,

I concur assuming that Stephen Farrell changes the PKIX AC profile to be
consistent with the draft 2000 X.509 Recommendation.  One solution would be
for Stephen to add a separate ASN.1 module that includes the
AttributeCertificate syntax and "DEFINITIONS IMPLICIT TAGS".  That is the
strategy used by the 2000 X.509 Recommendation.  

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================


-----Original Message-----
From: Sean P. Turner [mailto:[e-mail]]
Sent: Friday, March 23, 2001 3:11 AM
To: SMIME
Cc: Pawling, John; Stephen Farrell (E-mail)
Subject: Re: certificate and attribute certificate imported from PKIX or
X.509


Look I'm going to point to the PKIX AC profile unless somebody tells me not
to.
:)

"Pawling, John" wrote:

> All: Steve Henson is correct that the AttributeCertificate syntaxes are
> different in the draft 2000 X.509 Recommendation and PKIX AC profile.
>
> Stephen Farrell: Recommend that the PKIX AC profile be changed to be
> consistent with the draft 2000 X.509 Recommendation.
>
> Another PKIX AC profile Issue: X.501 defines the Clearance attribute
syntax
> using AUTOMATIC TAGS.  The Clearance attribute syntax in the PKIX AC
profile
> should be changed as follows to be consistent with X.501:
>
> Clearance ::= SEQUENCE
>  {
>      policyId
>          [0] OBJECT IDENTIFIER,
>      classList
>          [1] ClassList DEFAULT {unclassified},
>      securityCategories
>          [2] SET OF SecurityCategory OPTIONAL
>  }
>
> ===========================================
> John Pawling, [e-mail]
> Getronics Government Solutions, LLC
> ===========================================
>
> -----Original Message-----
> From: Dr S N Henson [mailto:[e-mail]]
> Sent: Thursday, March 22, 2001 4:33 PM
> To: SMIME
> Subject: Re: certificate and attribute certificate imported from PKIX or
> X.509
>
> "Pawling, John" wrote:
> >
> > Sean,
> >
> > The Certificate ASN.1 syntax definitions in the PKIX and X.509 specs are
> > equivalent (i.e. they produce identical hex ASN.1 encodings), so it
> doesn't
> > matter to me which spec is referenced.
> >
> > However, the AttributeCertificate syntax is an issue.  RFC 2630 imports
> the
> > AttributeCertificate syntax from the 1997 X.509 Recommendation.  The
> > AttributeCertificate syntax defined in the draft 2000 X.509
Recommendation
> > (X.509_4thEditionDraftV7, 23 Feb 2001) and PKIX AC Profile
> > (draft-ietf-pkix-ac509prof-06.txt, 10 Jan 2001) is incompatible with the
> > AttributeCertificate syntax defined in the 1997 X.509 Recommendation.
> > Recommend that the son-of-RFC2630 and symkeydist ASN.1 modules should
> import
> > the AttributeCertificate syntax defined in the draft 2000 X.509
> > Recommendation and PKIX AC Profile (again, it doesn't matter to me which
> > spec is referenced).
> >
>
> I'm trying to work out whether that statement implies that the draft2000
> X.509 Recommendation and the PKIX AC profile are compatible :-)
>
> I sent a query about that to the PKIX list without response a while ago.
> There seems to be one (unintentional?) incompatibility at least. The
> PKIX draft has in the ASN1 module (Appendix B):
>
> DEFINITIONS EXPLICIT TAGS ::=
>
> whereas the X509 2000 draft has:
>
> DEFINITIONS IMPLICIT TAGS ::=
>
> The 1997 X.509 recommendation apparently does not change the default
> tagging which would mean it should be EXPLICIT.
>
> I've only ever seen one example of an attribute certificate and that
> used default EXPLICIT tagging but it was broken in another separate way.
>
> Steve.
> --
> Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
> Personal Email: [e-mail]
> Senior crypto engineer, Celo Communications: http://www.celocom.com/
> Core developer of the   OpenSSL project: http://www.openssl.org/
> Business Email: [e-mail] PGP key: via homepage.


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id AAA06184 for ietf-smime-bks; Fri, 23 Mar 2001 00:16:24 -0800 (PST)
Received: from mr2.ash.ops.us.uu.net (mr2.ash.ops.us.uu.net [198.5.241.87]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA06177 for <[e-mail]>; Fri, 23 Mar 2001 00:16:23 -0800 (PST)
Received: from ieca.com by mr2.ash.ops.us.uu.net with ESMTP  (peer crosschecked as: 1Cust132.tnt1.minneapolis.mn.da.uu.net [63.11.42.132]) id QQkhoj08017; Fri, 23 Mar 2001 08:16:16 GMT
Message-ID: <[e-mail]>
Date: Fri, 23 Mar 2001 03:11:12 -0500
From: "Sean P. Turner" <[e-mail]>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: SMIME <[e-mail]>
CC: "Pawling, John" <[e-mail]>, "Stephen Farrell (E-mail)" <[e-mail]>
Subject: Re: certificate and attribute certificate imported from PKIX or X.509
References: <[e-mail]>
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>

Look I'm going to point to the PKIX AC profile unless somebody tells me not to.
:)

"Pawling, John" wrote:

> All: Steve Henson is correct that the AttributeCertificate syntaxes are
> different in the draft 2000 X.509 Recommendation and PKIX AC profile.
>
> Stephen Farrell: Recommend that the PKIX AC profile be changed to be
> consistent with the draft 2000 X.509 Recommendation.
>
> Another PKIX AC profile Issue: X.501 defines the Clearance attribute syntax
> using AUTOMATIC TAGS.  The Clearance attribute syntax in the PKIX AC profile
> should be changed as follows to be consistent with X.501:
>
> Clearance ::= SEQUENCE
>  {
>      policyId
>          [0] OBJECT IDENTIFIER,
>      classList
>          [1] ClassList DEFAULT {unclassified},
>      securityCategories
>          [2] SET OF SecurityCategory OPTIONAL
>  }
>
> ===========================================
> John Pawling, [e-mail]
> Getronics Government Solutions, LLC
> ===========================================
>
> -----Original Message-----
> From: Dr S N Henson [mailto:[e-mail]]
> Sent: Thursday, March 22, 2001 4:33 PM
> To: SMIME
> Subject: Re: certificate and attribute certificate imported from PKIX or
> X.509
>
> "Pawling, John" wrote:
> >
> > Sean,
> >
> > The Certificate ASN.1 syntax definitions in the PKIX and X.509 specs are
> > equivalent (i.e. they produce identical hex ASN.1 encodings), so it
> doesn't
> > matter to me which spec is referenced.
> >
> > However, the AttributeCertificate syntax is an issue.  RFC 2630 imports
> the
> > AttributeCertificate syntax from the 1997 X.509 Recommendation.  The
> > AttributeCertificate syntax defined in the draft 2000 X.509 Recommendation
> > (X.509_4thEditionDraftV7, 23 Feb 2001) and PKIX AC Profile
> > (draft-ietf-pkix-ac509prof-06.txt, 10 Jan 2001) is incompatible with the
> > AttributeCertificate syntax defined in the 1997 X.509 Recommendation.
> > Recommend that the son-of-RFC2630 and symkeydist ASN.1 modules should
> import
> > the AttributeCertificate syntax defined in the draft 2000 X.509
> > Recommendation and PKIX AC Profile (again, it doesn't matter to me which
> > spec is referenced).
> >
>
> I'm trying to work out whether that statement implies that the draft2000
> X.509 Recommendation and the PKIX AC profile are compatible :-)
>
> I sent a query about that to the PKIX list without response a while ago.
> There seems to be one (unintentional?) incompatibility at least. The
> PKIX draft has in the ASN1 module (Appendix B):
>
> DEFINITIONS EXPLICIT TAGS ::=
>
> whereas the X509 2000 draft has:
>
> DEFINITIONS IMPLICIT TAGS ::=
>
> The 1997 X.509 recommendation apparently does not change the default
> tagging which would mean it should be EXPLICIT.
>
> I've only ever seen one example of an attribute certificate and that
> used default EXPLICIT tagging but it was broken in another separate way.
>
> Steve.
> --
> Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
> Personal Email: [e-mail]
> Senior crypto engineer, Celo Communications: http://www.celocom.com/
> Core developer of the   OpenSSL project: http://www.openssl.org/
> Business Email: [e-mail] PGP key: via homepage.



Received: by above.proper.com (8.9.3/8.9.3) id OAA00642 for ietf-smime-bks; Thu, 22 Mar 2001 14:37:30 -0800 (PST)
Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA00632 for <[e-mail]>; Thu, 22 Mar 2001 14:37:28 -0800 (PST)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <Z2A49Z5H>; Thu, 22 Mar 2001 17:37:45 -0500
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: SMIME <[e-mail]>, "Stephen Farrell (E-mail)" <[e-mail]>
Subject: RE: certificate and attribute certificate imported from PKIX or X .509
Date: Thu, 22 Mar 2001 17:37:44 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
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: Steve Henson is correct that the AttributeCertificate syntaxes are
different in the draft 2000 X.509 Recommendation and PKIX AC profile.  

Stephen Farrell: Recommend that the PKIX AC profile be changed to be
consistent with the draft 2000 X.509 Recommendation.

Another PKIX AC profile Issue: X.501 defines the Clearance attribute syntax
using AUTOMATIC TAGS.  The Clearance attribute syntax in the PKIX AC profile
should be changed as follows to be consistent with X.501:

Clearance ::= SEQUENCE
 {
     policyId
         [0] OBJECT IDENTIFIER,
     classList
         [1] ClassList DEFAULT {unclassified},
     securityCategories
         [2] SET OF SecurityCategory OPTIONAL
 }

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================


-----Original Message-----
From: Dr S N Henson [mailto:[e-mail]]
Sent: Thursday, March 22, 2001 4:33 PM
To: SMIME
Subject: Re: certificate and attribute certificate imported from PKIX or
X.509


"Pawling, John" wrote:
> 
> Sean,
> 
> The Certificate ASN.1 syntax definitions in the PKIX and X.509 specs are
> equivalent (i.e. they produce identical hex ASN.1 encodings), so it
doesn't
> matter to me which spec is referenced.
> 
> However, the AttributeCertificate syntax is an issue.  RFC 2630 imports
the
> AttributeCertificate syntax from the 1997 X.509 Recommendation.  The
> AttributeCertificate syntax defined in the draft 2000 X.509 Recommendation
> (X.509_4thEditionDraftV7, 23 Feb 2001) and PKIX AC Profile
> (draft-ietf-pkix-ac509prof-06.txt, 10 Jan 2001) is incompatible with the
> AttributeCertificate syntax defined in the 1997 X.509 Recommendation.
> Recommend that the son-of-RFC2630 and symkeydist ASN.1 modules should
import
> the AttributeCertificate syntax defined in the draft 2000 X.509
> Recommendation and PKIX AC Profile (again, it doesn't matter to me which
> spec is referenced).
> 

I'm trying to work out whether that statement implies that the draft2000
X.509 Recommendation and the PKIX AC profile are compatible :-)

I sent a query about that to the PKIX list without response a while ago.
There seems to be one (unintentional?) incompatibility at least. The
PKIX draft has in the ASN1 module (Appendix B):

DEFINITIONS EXPLICIT TAGS ::=

whereas the X509 2000 draft has:

DEFINITIONS IMPLICIT TAGS ::=

The 1997 X.509 recommendation apparently does not change the default
tagging which would mean it should be EXPLICIT.

I've only ever seen one example of an attribute certificate and that
used default EXPLICIT tagging but it was broken in another separate way.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [e-mail] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [e-mail] PGP key: via homepage.


Received: by above.proper.com (8.9.3/8.9.3) id NAA25295 for ietf-smime-bks; Thu, 22 Mar 2001 13:28:52 -0800 (PST)
Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA25291 for <[e-mail]>; Thu, 22 Mar 2001 13:28:50 -0800 (PST)
Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=celocom.com) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 14gCdY-000Njf-0A for [e-mail]; Thu, 22 Mar 2001 21:28:52 +0000
Message-ID: <[e-mail]>
Date: Thu, 22 Mar 2001 21:33:00 +0000
From: Dr S N Henson <[e-mail]>
Organization: S N Henson
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: SMIME <[e-mail]>
Subject: Re: certificate and attribute certificate imported from PKIX or X.509
References: <[e-mail]>
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>

"Pawling, John" wrote:
> 
> Sean,
> 
> The Certificate ASN.1 syntax definitions in the PKIX and X.509 specs are
> equivalent (i.e. they produce identical hex ASN.1 encodings), so it doesn't
> matter to me which spec is referenced.
> 
> However, the AttributeCertificate syntax is an issue.  RFC 2630 imports the
> AttributeCertificate syntax from the 1997 X.509 Recommendation.  The
> AttributeCertificate syntax defined in the draft 2000 X.509 Recommendation
> (X.509_4thEditionDraftV7, 23 Feb 2001) and PKIX AC Profile
> (draft-ietf-pkix-ac509prof-06.txt, 10 Jan 2001) is incompatible with the
> AttributeCertificate syntax defined in the 1997 X.509 Recommendation.
> Recommend that the son-of-RFC2630 and symkeydist ASN.1 modules should import
> the AttributeCertificate syntax defined in the draft 2000 X.509
> Recommendation and PKIX AC Profile (again, it doesn't matter to me which
> spec is referenced).
> 

I'm trying to work out whether that statement implies that the draft2000
X.509 Recommendation and the PKIX AC profile are compatible :-)

I sent a query about that to the PKIX list without response a while ago.
There seems to be one (unintentional?) incompatibility at least. The
PKIX draft has in the ASN1 module (Appendix B):

DEFINITIONS EXPLICIT TAGS ::=

whereas the X509 2000 draft has:

DEFINITIONS IMPLICIT TAGS ::=

The 1997 X.509 recommendation apparently does not change the default
tagging which would mean it should be EXPLICIT.

I've only ever seen one example of an attribute certificate and that
used default EXPLICIT tagging but it was broken in another separate way.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [e-mail] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [e-mail] PGP key: via homepage.


Received: by above.proper.com (8.9.3/8.9.3) id MAA23646 for ietf-smime-bks; Thu, 22 Mar 2001 12:56:41 -0800 (PST)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA23639 for <[e-mail]>; Thu, 22 Mar 2001 12:56:38 -0800 (PST)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.7)); Thu, 22 Mar 2001 12:56:15 -0800
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by cane.deming.com with Internet Mail Service (5.5.2650.21) id <GFMMHNLS>; Thu, 22 Mar 2001 12:56:15 -0800
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, [e-mail]
Subject: RE: Mandatory to Implement Algorithms
Date: Thu, 22 Mar 2001 12:56:11 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 16A4B96579085-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>

Wow, and I wasn't even there.  Sweet!

I will update the drafts and have new ones posted soon.

Blake

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Thursday, March 22, 2001 12:00 PM
To: [e-mail]
Subject: Mandatory to Implement Algorithms


Dear Working Group:

At the face-to-face S/MIME WG meeting yesterday, we came to consensus on a 
new set of mandatory to implement algorithms.  The people present 
overwhelmingly agreed on the following:

	Encryption:	Triple-DES

	Key Mgmt:	RSA (using PKCS #1 v1.5)

	Msg Digest:	SHA-1

	Signature:	DSA and RSA  (using PKCS #1 v1.5)

On signature, we will require that implementations are able to verify 
signatures on certificates and messages using both algorithms; however, 
implementations are required to generates signatures on messages using at 
least one of the signature algorithms.

Russ




Received: by above.proper.com (8.9.3/8.9.3) id MAA18505 for ietf-smime-bks; Thu, 22 Mar 2001 12:00:04 -0800 (PST)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA18501 for <[e-mail]>; Thu, 22 Mar 2001 12:00:02 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 22 Mar 2001 19:57:53 UT
Received: from HOUSLEY-LAP.rsasecurity.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA01144; Thu, 22 Mar 2001 15:00:03 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 22 Mar 2001 14:59:56 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Mandatory to Implement Algorithms
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 Working Group:

At the face-to-face S/MIME WG meeting yesterday, we came to consensus on a 
new set of mandatory to implement algorithms.  The people present 
overwhelmingly agreed on the following:

	Encryption:	Triple-DES

	Key Mgmt:	RSA (using PKCS #1 v1.5)

	Msg Digest:	SHA-1

	Signature:	DSA and RSA  (using PKCS #1 v1.5)

On signature, we will require that implementations are able to verify 
signatures on certificates and messages using both algorithms; however, 
implementations are required to generates signatures on messages using at 
least one of the signature algorithms.

Russ



Received: by above.proper.com (8.9.3/8.9.3) id LAA15644 for ietf-smime-bks; Thu, 22 Mar 2001 11:17:42 -0800 (PST)
Received: from usrsrv1.meeting.ietf.org (smtp.meeting.ietf.org [135.222.20.40]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA15639 for <[e-mail]>; Thu, 22 Mar 2001 11:17:41 -0800 (PST)
Received: from ieca.com (pcp009793pcs.laptops.meeting.ietf.org [135.222.33.59]) by usrsrv1.meeting.ietf.org (8.11.2/8.11.2) with ESMTP id f2MJHdt15724 for <[e-mail]>; Thu, 22 Mar 2001 13:17:39 -0600 (CST)
Message-ID: <[e-mail]>
Date: Thu, 22 Mar 2001 14:12:40 -0500
From: "Sean P. Turner" <[e-mail]>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: SMIME <[e-mail]>
Subject: Re: certificate and attribute certificate imported from PKIX or X.509
References: <[e-mail]>
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>

John,

Thanks for the quick though.  I guess I'd rather use the PKIX references just
because it is an IETF standard :)

spt

"Pawling, John" wrote:

> Sean,
>
> The Certificate ASN.1 syntax definitions in the PKIX and X.509 specs are
> equivalent (i.e. they produce identical hex ASN.1 encodings), so it doesn't
> matter to me which spec is referenced.
>
> However, the AttributeCertificate syntax is an issue.  RFC 2630 imports the
> AttributeCertificate syntax from the 1997 X.509 Recommendation.  The
> AttributeCertificate syntax defined in the draft 2000 X.509 Recommendation
> (X.509_4thEditionDraftV7, 23 Feb 2001) and PKIX AC Profile
> (draft-ietf-pkix-ac509prof-06.txt, 10 Jan 2001) is incompatible with the
> AttributeCertificate syntax defined in the 1997 X.509 Recommendation.
> Recommend that the son-of-RFC2630 and symkeydist ASN.1 modules should import
> the AttributeCertificate syntax defined in the draft 2000 X.509
> Recommendation and PKIX AC Profile (again, it doesn't matter to me which
> spec is referenced).
>
> ===========================================
> John Pawling, [e-mail]
> Getronics Government Solutions, LLC
> ===========================================
>
>
> -----Original Message-----
> From: Sean P. Turner [mailto:[e-mail]]
> Sent: Thursday, March 22, 2001 11:30 AM
> To: SMIME
> Subject: certificate and attribute certificate imported from PKIX or
> X.509
>
> All,
>
> One of the comments I received on the symkeydist draft was to import
> certificate and attribute certificate from the PKIX documents and not
> from X.509.  The question is whether I should do this or not and if so
> should CMS be changed to do the same?
>
> spt



Received: by above.proper.com (8.9.3/8.9.3) id KAA13491 for ietf-smime-bks; Thu, 22 Mar 2001 10:41:28 -0800 (PST)
Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA13486 for <[e-mail]>; Thu, 22 Mar 2001 10:41:25 -0800 (PST)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <Z2A49XTN>; Thu, 22 Mar 2001 13:41:40 -0500
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: SMIME <[e-mail]>
Subject: RE: certificate and attribute certificate imported from PKIX or X .509
Date: Thu, 22 Mar 2001 13:41:39 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
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>

Sean,

The Certificate ASN.1 syntax definitions in the PKIX and X.509 specs are
equivalent (i.e. they produce identical hex ASN.1 encodings), so it doesn't
matter to me which spec is referenced.

However, the AttributeCertificate syntax is an issue.  RFC 2630 imports the
AttributeCertificate syntax from the 1997 X.509 Recommendation.  The
AttributeCertificate syntax defined in the draft 2000 X.509 Recommendation
(X.509_4thEditionDraftV7, 23 Feb 2001) and PKIX AC Profile
(draft-ietf-pkix-ac509prof-06.txt, 10 Jan 2001) is incompatible with the
AttributeCertificate syntax defined in the 1997 X.509 Recommendation.
Recommend that the son-of-RFC2630 and symkeydist ASN.1 modules should import
the AttributeCertificate syntax defined in the draft 2000 X.509
Recommendation and PKIX AC Profile (again, it doesn't matter to me which
spec is referenced).

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================
 

-----Original Message-----
From: Sean P. Turner [mailto:[e-mail]]
Sent: Thursday, March 22, 2001 11:30 AM
To: SMIME
Subject: certificate and attribute certificate imported from PKIX or
X.509


All,

One of the comments I received on the symkeydist draft was to import
certificate and attribute certificate from the PKIX documents and not
from X.509.  The question is whether I should do this or not and if so
should CMS be changed to do the same?

spt



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA04595 for ietf-smime-bks; Thu, 22 Mar 2001 08:35:48 -0800 (PST)
Received: from mr2.ash.ops.us.uu.net (mr2.ash.ops.us.uu.net [198.5.241.87]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA04586 for <[e-mail]>; Thu, 22 Mar 2001 08:35:46 -0800 (PST)
Received: from ieca.com by mr2.ash.ops.us.uu.net with ESMTP  (peer crosschecked as: 1Cust12.tnt5.minneapolis.mn.da.uu.net [63.11.57.12]) id QQkhly03702 for <[e-mail]>; Thu, 22 Mar 2001 16:35:41 GMT
Message-ID: <[e-mail]>
Date: Thu, 22 Mar 2001 11:30:06 -0500
From: "Sean P. Turner" <[e-mail]>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: SMIME <[e-mail]>
Subject: certificate and attribute certificate imported from PKIX or X.509
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>

All,

One of the comments I received on the symkeydist draft was to import
certificate and attribute certificate from the PKIX documents and not
from X.509.  The question is whether I should do this or not and if so
should CMS be changed to do the same?

spt




Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id LAA23392 for ietf-smime-bks; Wed, 21 Mar 2001 11:30:42 -0800 (PST)
Received: from usrsrv1.meeting.ietf.org (smtp.meeting.ietf.org [135.222.20.40]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA23386 for <[e-mail]>; Wed, 21 Mar 2001 11:30:31 -0800 (PST)
Received: from ieca.com (pcp009793pcs.laptops.meeting.ietf.org [135.222.33.59]) by usrsrv1.meeting.ietf.org (8.11.2/8.11.2) with ESMTP id f2LJUKw12535 for <[e-mail]>; Wed, 21 Mar 2001 13:30:20 -0600 (CST)
Message-ID: <[e-mail]>
Date: Wed, 21 Mar 2001 14:25:24 -0500
From: "Sean P. Turner" <[e-mail]>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: SMIME <[e-mail]>
Subject: comments on draft-ietf-smime-symkeydist-02.txt
Content-Type: multipart/alternative; boundary="------------A1B4D75523F0B7591337C85C"
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>

--------------A1B4D75523F0B7591337C85C
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

All,

Here were the comments that I received on
draft-ietf-smime-symkeydist-02.txt (used these to generate the current
-03 version):

Line 359 - upper case glAddMember as Syntax

Okay

Line 379 - Define what O, R and F mean.

Modified paragraph before conformance tables to indicate that O is
originate, R is receive, and F if forward.

Line 379 - In pre-table text.  GLO and GLA/O are MAY.  Then up some MAYs
to MUST within the table

After some discussion, I decided to split the tables to indicate the
required messages and optional messages and to rewrite the paragraph
that came before the tables.  I also changed "N/A" to "-" for
readability reasons.  GLOs are now clearly indicated as an optional
implementation.  Hopefully people will let me know if I got it right.

Line 379 - Add new column to GLA F-GLO and F-GLM?

I think after the changes I made a result of the other columns aren't
needed (or maybe I didn't understand why they were needed in the first
place).

Line 420 - [0] is not needed unless another optional item is to be
added.

Removed it.

Line 441 - Can't be both default and optional

Removed the "OPTIONAL"

Line 449 - Both name and address unique or combination is unique - be
specific.

I want to make sure the GL name and the address is unique for a given
GLA.

Line 500 - Text and title are reverse sense of each other.

Ended up changing the titles to be more "user friendly."

Line 522 - Are dates & times to be UTC or local?

I made them UTC.

Line 546 - Appears to be more the generation algorithm and not the CEK
algorithm from the text description

I ended up changing the sentence to say: "requestedAlgorithm indicates
the algorithm and any parameters the GLO wants the GLA to use with the
shared KEK. "

Line 585 - SEQUENCE (1..MAX) OF ...

Added the (1..MAX)

Line 590 - either import or ditto above

okay ... decided to copy above.

Line 605 - glMember.glmemberName and glMember.glMemberAddress must be
unique

Added a sentence to indicate that the two must unique.

Line 605 - Formatting - break down sub-field items into bulleted list

okay

Line 624 - Simplify "and GL members use glDeleteMember to request..."

okay

Line 680 - Why use special value of generationCounter rather than a new
field?

After some discussion I was convinced and have added a new field called:
"glRekeyAllGLKeys indicates whether the GLO wants all of the outstanding
GL’s shared KEKs rekeyed. If it is set to TRUE then all outstanding KEKs
MUST be issued. If it is set to FALSE then all outstanding KEKs need not
be resissued."

Line 700 - Where is the new GLO certificate? - missing field from
GLOwnerInfo?

At first I thought we should just use the update certificate message,
but I have been convinced that we should add a "certificates" field to
the GLOwnerInfo field.  Unfortunately, I didn't get convinced until
after I'd submitted it, so it will have to wait until the next draft.

Line 719 - Syntax "MUST be signed a registered"

changed it to "MUST be signed by a registered"

Line 721 - How to I replace a GLO for an unmanaged list?

I was being to restrictive by not allowing multiple GLOs for unmanaged
lists.  I have removed this restriction.

Line 760 - glkRefresh still has not date component in it.

Added a date field, but this ended up changing a few other things.

Line 765 - Change the GLSuccess structure - need tag id

This is going to get removed.

Line 838 - ditto for GLFailInfo

See above

Line 876 - could you both return this and forward request to GLO?

That would certainly make it more friendly.  I added a sentence to say
it was up GL policy (in section 3.1.1) to forward a request when it’s an
closed GL.

Line 970 - is certificate optional for glAddMember?  sends out a
glProvideCert to the member to be added.

The end result was that I ended up changing GLProvideCert by replacing
glMemberName with glMember and making GLMember.certificates be optional
(and stated that it SHOULD be omitted from GLProvideCert and that it
MUST be included in GLUpdateCert).

Line 1007 - are both required or is GeneralName sufficent -- this is all
that is sent the the preceeding message.

I made the address optional in this case.

Line 1013 - bullet sub-field items

okay

Line 1037 - I think you should allow for additional items here? Maybe?

I'll make this change in the next version (i.e., I'll use
KEKIdentifier).

Line 1057 - caps must

okay

Line 1061 - make it the ktri must be supported

I may have overstepped my pay grade here but I changed it to be the ktri
choice as a result of the group's sentiment in San Diego.

Line 1061 - sentence #2 needs some re-writing

okay

Line 1066 - Is the IV encoded here or S/MIME Caps for parameter

I'll make a change in the next version.

Line 1088 - not strict enough - must generate unique messages for each
receipient each containg a glKey attribute for the single recipient.

Added the following: "For each recipient you want to generate a message
that contains that recipient’s key (i.e., one message with one
attribute)."

Line 1116 - why this and not always have X current keys.

Changed it to say: "The GLA MUST generate X number of glKey messages,
where X is the number of outstanding shared KEKs for the GL if
glRekeyAllGLKeys is set to TRUE."

Line 1178 - Add if possible - consider encrypted updateCert with bad
cert.

I actually avoided this on purpose.

Line 1186 - Confidentality between the GLA and GLO may be provided by
other methods thus the encrytion layer can be omitted in these cases.

I ended up stating that "confidentiality MUST be preserved"

Line 1190 - typo Mutlipe

okay

Line 1214 - Might as well be "one or more requests"

okay

Line 1271 - I'm not sure about this one.  I need to think about it.

Ended up removing that combination

Line 1274 - does this imply an order of items in the message - state so
either way.

Added the following: "It should be noted that there is a priority but it
does not imply an order."

Line 1292 - Incorrect - responses to GLOs may be lumped together.

Added the following: "It is valid to send one message with multiple
attributes to the same recipient."

Unknown - No status messasge is expected to be returned by a client to a
glKey attribute.

Need to add that in the -04 version.

Line 1406 - This is generated by the GLA not the GLO. -- Send suggested
text & new fail structure from CMC.

Need to make these changes in the -04 version.

Line 1431 - possible way to handle this.  THere are others.

okay.

Unknown - Put in a UTF8String statement for DN's

Added it to the PKIX section.

Line 1489 - "glAddMember request(s)"

okay

Line 1513 - Do we need to be able to pass an asymmetric key & cert to
the GLA?

I added: "Instead of immediately returning the error code, the GLA MAY
attempt to get a certificate, possibly using CMC [3]."

Line 1525 - "Must check that glAddress is not already in use"

Good catch.

Line 1586 - Why would you return a response to a response?

Jsut trying to be preceise.  Probably have to fix this in the -04
version.

Line 1586 - What is correct GLA response to this?  Not covered in CMC.

okay.

Line 1515 - Should the DN for the GLA certificate include the GL name or
that of the GLA?

I made it be the DN Of the GL. Not sure if this is right but I'll await
comments.

Line 1758 - I disagree with the MUST

Made it a "MAY".

Line 1775 - lower case the MAY.

okay

Line 1918 - Do you need to verify that the glMembers name or address is
contained in the certificate

I put in that:"The GL policy may mandate that the GL member’s address be
included in the GL member’s certificate."

Section 4.4.1 - If list is closed and rekey is missing is there a GLA
response?
        2.b.2.b.1.b and 1 different on the requirement of who must do
the re-key

Okay what I did was change the last sentence to say: “Note that he GL
MUST also be rekeyed as described in paragraph 5.”  That way I’m not
saying who has to do the rekey (it depends on who controls the list).  I
made the same change to 2.b.2.b.2.b.  It now matches that it’s option to
rekey the GL.

Line 2196 - "a _" should be "a -"

okay

Section 4.4.2 - Item 1 - omission of the glIdentifier should be deleted

Okay.

Section 4.4.2 - Item 3 - Need to state it is not for open lists. "If a
GLO recieves a a forwarded request, ...."

I added the following to item 3 in 4.3.2 and 4.4.2 where the GLO could
receive a forwarded request: “Note: For cases where the GL is closed and
either a) a prospective member sends directly to the GLO or b) the GLA
has mistakenly forwarded the request to the GLO, the GLO should first
determine whether to honor the request.”

Section 4.4.2 - Section 3.b.2 - Why is there text about once and only
once in the list?  Which list is being refered to the delete list or the
mail list?

I changed to say “GL” instead of “list.”  I deleted the part about once
and only once.

General Comment - You keep referencing things like paragraph 5 -- to me
this should be Section 5.  Paragraphs are seperated by CRs and Sections
are numbered.

Changed "sections" to be "paragraphs"

Section 4.5 - Paragraph 9 - GLA can do an automatic rekey on key
compromise for GLA rekey lists.

I changed to indicate as much.

General - I don't know where this goes.  Should state that if a
signature outside of an encryption layer is added, the "Content-Hint"
attribute must be included in the outer signature.

Agree, but it didn't make it into the -03 version, will put it in the
-04 version.

Section 4.5.2 - "1 _" not "1 -"

OKay.

Figure 8 - "8 _" to "8 -" ----- Global search for this

OKay.

Figure 10 - Should be a single member not multiple members.

Fixed.

Section 4.8 - The response message is missing from the steps.

This missed going into the -03 version will include it in the -04
version.

Section 4.9 - 2.b - "GLAQueryReuests"

Fixed.

Section 4.9 - GLAQueryRequest/Response can be betweeen GLA and member

Okay changed it to indicate as much.

Section 4.9 - 2.b.2 - Make this more general -- "With the correct
response for the qeusts".

Fixed.

Section 5 - Did we have the kari vs ktri discussion?

After San Diego, I decided to change it to ktri.

Section 5 - I really don't like the idea of using kekri for distribution
of keys.  This means that breaking key #1 means you can chain through
and get the rest of them.

Have some text, but it didn't make it in the -03 version.  Will include
it in the -04 version.

Section 9 - Text is missing

Added some, let me know what you think.

Cheers,

spt

--------------A1B4D75523F0B7591337C85C
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
All,
<p>Here were the comments that I received on draft-ietf-smime-symkeydist-02.txt
(used these to generate the current -03 version):
<p>Line 359 - upper case glAddMember as Syntax
<p>Okay
<p>Line 379 - Define what O, R and F mean.
<p>Modified paragraph before conformance tables to indicate that O is originate,
R is receive, and F if forward.
<p>Line 379 - In pre-table text.&nbsp; GLO and GLA/O are MAY.&nbsp; Then
up some MAYs to MUST within the table
<p>After some discussion, I decided to split the tables to indicate the
required messages and optional messages and to rewrite the paragraph that
came before the tables.&nbsp; I also changed "N/A" to "-" for readability
reasons.&nbsp; GLOs are now clearly indicated as an optional implementation.&nbsp;
Hopefully people will let me know if I got it right.
<p>Line 379 - Add new column to GLA F-GLO and F-GLM?
<p>I think after the changes I made a result of the other columns aren't
needed (or maybe I didn't understand why they were needed in the first
place).
<p>Line 420 - [0] is not needed unless another optional item is to be added.
<p>Removed it.
<p>Line 441 - Can't be both default and optional
<p>Removed the "OPTIONAL"
<p>Line 449 - Both name and address unique or combination is unique - be
specific.
<p>I want to make sure the GL name and the address is unique for a given
GLA.
<p>Line 500 - Text and title are reverse sense of each other.
<p>Ended up changing the titles to be more "user friendly."
<p>Line 522 - Are dates &amp; times to be UTC or local?
<p>I made them UTC.
<p>Line 546 - Appears to be more the generation algorithm and not the CEK
algorithm from the text description
<p>I ended up changing the sentence to say: "requestedAlgorithm indicates
the algorithm and any parameters the GLO wants the GLA to use <u>with</u>
the shared KEK. "
<p>Line 585 - SEQUENCE (1..MAX) OF ...
<p>Added the (1..MAX)
<p>Line 590 - either import or ditto above
<p>okay ... decided to copy above.
<p>Line 605 - glMember.glmemberName and glMember.glMemberAddress must be
unique
<p>Added a sentence to indicate that the two must unique.
<p>Line 605 - Formatting - break down sub-field items into bulleted list
<p>okay
<p>Line 624 - Simplify "and GL members use glDeleteMember to request..."
<p>okay
<p>Line 680 - Why use special value of generationCounter rather than a
new field?
<p>After some discussion I was convinced and have added a new field called:
"glRekeyAllGLKeys indicates whether the GLO wants all of the outstanding
GL’s shared KEKs rekeyed. If it is set to TRUE then all outstanding KEKs
MUST be issued. If it is set to FALSE then all outstanding KEKs need not
be resissued."
<p>Line 700 - Where is the new GLO certificate? - missing field from GLOwnerInfo?
<p>At first I thought we should just use the update certificate message,
but I have been convinced that we should add a "certificates" field to
the GLOwnerInfo field.&nbsp; Unfortunately, I didn't get convinced until
after I'd submitted it, so it will have to wait until the next draft.
<p>Line 719 - Syntax "MUST be signed a registered"
<p>changed it to "MUST be signed by a registered"
<p>Line 721 - How to I replace a GLO for an unmanaged list?
<p>I was being to restrictive by not allowing multiple GLOs for unmanaged
lists.&nbsp; I have removed this restriction.
<p>Line 760 - glkRefresh still has not date component in it.
<p>Added a date field, but this ended up changing a few other things.
<p>Line 765 - Change the GLSuccess structure - need tag id
<p>This is going to get removed.
<p>Line 838 - ditto for GLFailInfo
<p>See above
<p>Line 876 - could you both return this and forward request to GLO?
<p>That would certainly make it more friendly.&nbsp; I added a sentence
to say it was up GL policy (in section 3.1.1) to forward a request when
it’s an closed GL.
<p>Line 970 - is certificate optional for glAddMember?&nbsp; sends out
a glProvideCert to the member to be added.
<p>The end result was that I ended up changing GLProvideCert by replacing
glMemberName with glMember and making GLMember.certificates be optional
(and stated that it SHOULD be omitted from GLProvideCert and that it MUST
be included in GLUpdateCert).
<p>Line 1007 - are both required or is GeneralName sufficent -- this is
all that is sent the the preceeding message.
<p>I made the address optional in this case.
<p>Line 1013 - bullet sub-field items
<p>okay
<p>Line 1037 - I think you should allow for additional items here? Maybe?
<p>I'll make this change in the next version (i.e., I'll use KEKIdentifier).
<p>Line 1057 - caps must
<p>okay
<p>Line 1061 - make it the ktri must be supported
<p>I may have overstepped my pay grade here but I changed it to be the
ktri choice as a result of the group's sentiment in San Diego.
<p>Line 1061 - sentence #2 needs some re-writing
<p>okay
<p>Line 1066 - Is the IV encoded here or S/MIME Caps for parameter
<p>I'll make a change in the next version.
<p>Line 1088 - not strict enough - must generate unique messages for each
receipient each containg a glKey attribute for the single recipient.
<p>Added the following: "For each recipient you want to generate a message
that contains that recipient’s key (i.e., one message with one attribute)."
<p>Line 1116 - why this and not always have X current keys.
<p>Changed it to say: "The GLA MUST generate X number of glKey messages,
where X is the number of outstanding shared KEKs for the GL if glRekeyAllGLKeys
is set to TRUE."
<p>Line 1178 - Add if possible - consider encrypted updateCert with bad
cert.
<p>I actually avoided this on purpose.
<p>Line 1186 - Confidentality between the GLA and GLO may be provided by
other methods thus the encrytion layer can be omitted in these cases.
<p>I ended up stating that "confidentiality MUST be preserved"
<p>Line 1190 - typo Mutlipe
<p>okay
<p>Line 1214 - Might as well be "one or more requests"
<p>okay
<p>Line 1271 - I'm not sure about this one.&nbsp; I need to think about
it.
<p>Ended up removing that combination
<p>Line 1274 - does this imply an order of items in the message - state
so either way.
<p>Added the following: "It should be noted that there is a priority but
it does not imply an order."
<p>Line 1292 - Incorrect - responses to GLOs may be lumped together.
<p>Added the following: "It is valid to send one message with multiple
attributes to the same recipient."
<p>Unknown - No status messasge is expected to be returned by a client
to a glKey attribute.
<p>Need to add that in the -04 version.
<p>Line 1406 - This is generated by the GLA not the GLO. -- Send suggested
text &amp; new fail structure from CMC.
<p>Need to make these changes in the -04 version.
<p>Line 1431 - possible way to handle this.&nbsp; THere are others.
<p>okay.
<p>Unknown - Put in a UTF8String statement for DN's
<p>Added it to the PKIX section.
<p>Line 1489 - "glAddMember request(s)"
<p>okay
<p>Line 1513 - Do we need to be able to pass an asymmetric key &amp; cert
to the GLA?
<p>I added: "Instead of immediately returning the error code, the GLA MAY
attempt to get a certificate, possibly using CMC [3]."
<p>Line 1525 - "Must check that glAddress is not already in use"
<p>Good catch.
<p>Line 1586 - Why would you return a response to a response?
<p>Jsut trying to be preceise.&nbsp; Probably have to fix this in the -04
version.
<p>Line 1586 - What is correct GLA response to this?&nbsp; Not covered
in CMC.
<p>okay.
<p>Line 1515 - Should the DN for the GLA certificate include the GL name
or that of the GLA?
<p>I made it be the DN Of the GL. Not sure if this is right but I'll await
comments.
<p>Line 1758 - I disagree with the MUST
<p>Made it a "MAY".
<p>Line 1775 - lower case the MAY.
<p>okay
<p>Line 1918 - Do you need to verify that the glMembers name or address
is contained in the certificate
<p>I put in that:"The GL policy may mandate that the GL member’s address
be included in the GL member’s certificate."
<p>Section 4.4.1 - If list is closed and rekey is missing is there a GLA
response?
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2.b.2.b.1.b and 1 different
on the requirement of who must do the re-key
<p>Okay what I did was change the last sentence to say: “Note that he GL
MUST also be rekeyed as described in paragraph 5.”&nbsp; That way I’m not
saying who has to do the rekey (it depends on who controls the list).&nbsp;
I made the same change to 2.b.2.b.2.b.&nbsp; It now matches that it’s option
to rekey the GL.
<p>Line 2196 - "a _" should be "a -"
<p>okay
<p>Section 4.4.2 - Item 1 - omission of the glIdentifier should be deleted
<p>Okay.
<p>Section 4.4.2 - Item 3 - Need to state it is not for open lists. "If
a GLO recieves a a forwarded request, ...."
<p>I added the following to item 3 in 4.3.2 and 4.4.2 where the GLO could
receive a forwarded request: “Note: For cases where the GL is closed and
either a) a prospective member sends directly to the GLO or b) the GLA
has mistakenly forwarded the request to the GLO, the GLO should first determine
whether to honor the request.”
<p>Section 4.4.2 - Section 3.b.2 - Why is there text about once and only
once in the list?&nbsp; Which list is being refered to the delete list
or the mail list?
<p>I changed to say “GL” instead of “list.”&nbsp; I deleted the part about
once and only once.
<p>General Comment - You keep referencing things like paragraph 5 -- to
me this should be Section 5.&nbsp; Paragraphs are seperated by CRs and
Sections are numbered.
<p>Changed "sections" to be "paragraphs"
<p>Section 4.5 - Paragraph 9 - GLA can do an automatic rekey on key compromise
for GLA rekey lists.
<p>I changed to indicate as much.
<p>General - I don't know where this goes.&nbsp; Should state that if a
signature outside of an encryption layer is added, the "Content-Hint" attribute
must be included in the outer signature.
<p>Agree, but it didn't make it into the -03 version, will put it in the
-04 version.
<p>Section 4.5.2 - "1 _" not "1 -"
<p>OKay.
<p>Figure 8 - "8 _" to "8 -" ----- Global search for this
<p>OKay.
<p>Figure 10 - Should be a single member not multiple members.
<p>Fixed.
<p>Section 4.8 - The response message is missing from the steps.
<p>This missed going into the -03 version will include it in the -04 version.
<p>Section 4.9 - 2.b - "GLAQueryReuests"
<p>Fixed.
<p>Section 4.9 - GLAQueryRequest/Response can be betweeen GLA and member
<p>Okay changed it to indicate as much.
<p>Section 4.9 - 2.b.2 - Make this more general -- "With the correct response
for the qeusts".
<p>Fixed.
<p>Section 5 - Did we have the kari vs ktri discussion?
<p>After San Diego, I decided to change it to ktri.
<p>Section 5 - I really don't like the idea of using kekri for distribution
of keys.&nbsp; This means that breaking key #1 means you can chain through
and get the rest of them.
<p>Have some text, but it didn't make it in the -03 version.&nbsp; Will
include it in the -04 version.
<p>Section 9 - Text is missing
<p>Added some, let me know what you think.
<p>Cheers,
<p>spt</html>

--------------A1B4D75523F0B7591337C85C--



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id FAA26615 for ietf-smime-bks; Wed, 21 Mar 2001 05:21:01 -0800 (PST)
Received: from post.ffi.no (post.ffi.no [193.156.99.133]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA26608 for <[e-mail]>; Wed, 21 Mar 2001 05:20:57 -0800 (PST)
Received: by post.ffi.no with Internet Mail Service (5.5.2653.19) id <G85MJ3LL>; Wed, 21 Mar 2001 14:20:45 +0100
Message-ID: <[e-mail]>
From: "Eggen, Anders" <[e-mail]>
To: "'Prasad, Nandi'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: SV: S/MIME support in SMTP Gateway
Date: Wed, 21 Mar 2001 14:20:41 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B209.BA4B22F0"
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_001_01C0B209.BA4B22F0
Content-Type: text/plain;
	charset="iso-8859-1"

Nandiprasad J.M,

a) 
	What I understand about the "draft-ietf-smime-x400transport" is that
one 
	 has to transport the CMS object as a seperate content with the
	"content-type"  field pf the P1 envelope containing OIDs {1 2 840
113549 1 7 1}  ( if
	the CMS object has a MIME wrapper) or {1 2 840 113549 1 9 16 1 6}
(If the CMS
	object doesn't have a MIME wrapper).
Your assumption is correct.

b)
	To be more precise X.400 MTA's functionality is to just transfer
message
	based on the information available in the P1 envelope, without
bothering about
	the syntax of the content. Is my assumption correct?

Your assumption is correct. It is the User Agent that has to be able to
process the format of the content. 
c) 
	X.420 (1999) recomendations defines PKCS7 as one of standard IPM
	bodyparts.Since CMS is derived from or is a subset of PKCS7, can it
be used to convey
	CMS object into X.400 from Internet?
I assume this should be possible, I have to look into this and come back to
you. 
Has anybody else looked into this?

Anders Eggen


> -----Opprinnelig melding-----
> Fra:	Prasad, Nandi [SMTP:[e-mail]]
> Sendt:	Wednesday, March 21, 2001 12:35 PM
> Til:	'[e-mail]'
> Emne:	S/MIME support in SMTP Gateway
> 
> Hello everybody
> 
> 	I am working in a project which invloves S/MIME support in the SMTP
> Gateway which acts as a gateway between Internet and X.400 world. Our
> Gateway
> is connected to X.400 MTA and converts any Internet message (text/MIME)
> onto
> 
> equivalent X.400 IPM and vice versa.
> 
> 	At this point of time what we expect to do is convert/tunnel the
> incoming 
> S/MIME message from Internet into X.400.I have gone through many documents
> 
> but haven't found any clear information about S/MIME support in X.400. The
> current 
> drafts "draft-ietf-smime-x400transport" and  "draft-ietf-smime-x400wrap"
> gives me 
> some information about transporting S/MIME in X.400.
> 
> 	I have some queries about them and they are as follows:
> 
> a) What I understand about the "draft-ietf-smime-x400transport" is that
> one 
>     has to transport the CMS object as a seperate content with the
> "content-type" 
>     field pf the P1 envelope containing OIDs {1 2 840 113549 1 7 1}  ( if
> the CMS
>     object has a MIME wrapper) or {1 2 840 113549 1 9 16 1 6} (If the CMS
> object 
>     doesn't have a MIME wrapper).
> 
> b) Coming to the transport of S/MIME messages from Internet to X.400 via a
> SMTP 
>     gateway,  I assume that the format of the message that arrives at the
> Gateway 
>     from Internet will be according to RFC 2633( i.e S/MIME Version 3
> Message 
>     specification). The Gateway has to suitably interpret the S/MIME
> message
> and 
>     build an equivalent X.400 message with the CMS object solely being the
> content 
>     of the X.400 message and vice versa for a message that comes from
> X.400
> side.
>     To be more precise X.400 MTA's functionality is to just transfer
> message
> based
>     on the information available in the P1 envelope, without bothering
> about
> the 
>     syntax of the content. Is my assumption correct?
> 
> c) X.420 (1999) recomendations defines PKCS7 as one of standard IPM
> bodyparts.Since
>     CMS is derived from or is a subset of PKCS7, can it be used to convey
> CMS object 
>     into X.400 from Internet?
> 
> I am using Microsoft Exchange Server connected to our X.400 MTA via the
> Exchange 
> X.400 connector for testing purposes. We use Exchange server as a S/MIME
> UA.
> The
> test setup is  briefly as follows:
> 
> 
> Internet <------> SMTP Gateway <----> X.400 MTA
> <------------------------->
> Exchange MTA 
> 				      (Digital)          X.400 connector
> ( Microsoft)
> 
> 	Our Gateway follows the RFCs MIME, MIXER and creates an IPM
> accordingly in
> X.400. We have our own MTA which supports IPM( 1984 and 1988), IPN, EDI
> messages.
> 
> 
> 	Can anyone clarify my doubts/assumptions.
> 
> Regards
> Nandiprasad J.M

------_=_NextPart_001_01C0B209.BA4B22F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>SV: S/MIME support in SMTP Gateway</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Nandiprasad =
J.M</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">a) </FONT>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">What I understand about the =
&quot;draft-ietf-smime-x400transport&quot; is that one </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;has to transport the CMS object =
as a seperate content with the</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&quot;content-type&quot;</FONT>&nbsp;<FONT SIZE=3D2 =
FACE=3D"Arial"></FONT> <FONT SIZE=3D2 FACE=3D"Arial">field pf the P1 =
envelope containing OIDs {1 2 840 113549 1 7 1}&nbsp; ( if</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the CMS</FONT><FONT SIZE=3D2 =
FACE=3D"Arial"></FONT> <FONT SIZE=3D2 FACE=3D"Arial">object has a MIME =
wrapper) or {1 2 840 113549 1 9 16 1 6} (If the CMS</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">object doesn't have a MIME =
wrapper).</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Your assumption is =
correct.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">b)</FONT>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">To be more precise X.400 MTA's =
functionality is to just transfer message</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">based</FONT><FONT SIZE=3D2 =
FACE=3D"Arial"></FONT> <FONT SIZE=3D2 FACE=3D"Arial">on the information =
available in the P1 envelope, without bothering about</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the syntax of the content. Is my =
assumption correct?</FONT>
</P>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Your assumption is =
correct. It is the User Agent that has to be able to process the format =
of the content. </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">c) </FONT>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">X.420 (1999) recomendations defines =
PKCS7 as one of standard IPM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">bodyparts.Since</FONT><FONT SIZE=3D2 =
FACE=3D"Arial"></FONT> <FONT SIZE=3D2 FACE=3D"Arial">CMS is derived =
from or is a subset of PKCS7, can it be used to convey</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">CMS object into X.400 from =
Internet?</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I assume this should =
be possible, I have to look into this and come back to you. </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Has anybody else =
looked into this?</FONT>
</P>

<P><B><FONT FACE=3D"Brush Script MT">Anders Eggen</FONT></B>
</P>
<BR>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Opprinnelig melding-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Fra:&nbsp;&nbsp;&nbsp;</FONT></B> =
<FONT SIZE=3D1 FACE=3D"Arial">Prasad, Nandi =
[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sendt:&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Wednesday, March 21, 2001 12:35 PM</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Til:&nbsp;&nbsp;&nbsp;</FONT></B> =
<FONT SIZE=3D1 FACE=3D"Arial">'[e-mail]'</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Emne:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">S/MIME support in SMTP Gateway</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hello everybody</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">I am working in a project which invloves S/MIME support =
in the SMTP</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Gateway which acts as a gateway =
between Internet and X.400 world. Our</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Gateway</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">is connected to X.400 MTA and =
converts any Internet message (text/MIME) onto</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">equivalent X.400 IPM and vice =
versa.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">At this point of time what we expect to do is =
convert/tunnel the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">incoming </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">S/MIME message from Internet into =
X.400.I have gone through many documents </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">but haven't found any clear =
information about S/MIME support in X.400. The</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">current </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">drafts =
&quot;draft-ietf-smime-x400transport&quot; and&nbsp; =
&quot;draft-ietf-smime-x400wrap&quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">gives me </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">some information about transporting =
S/MIME in X.400.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">I have some queries about them and they are as =
follows:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">a) What I understand about the =
&quot;draft-ietf-smime-x400transport&quot; is that one </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; has to transport =
the CMS object as a seperate content with the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;content-type&quot; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; field pf the P1 =
envelope containing OIDs {1 2 840 113549 1 7 1}&nbsp; ( if</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the CMS</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; object has a MIME =
wrapper) or {1 2 840 113549 1 9 16 1 6} (If the CMS</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">object </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; doesn't have a =
MIME wrapper).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">b) Coming to the transport of S/MIME =
messages from Internet to X.400 via a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">SMTP </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; gateway,&nbsp; I =
assume that the format of the message that arrives at the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Gateway </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; from Internet will =
be according to RFC 2633( i.e S/MIME Version 3</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Message </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; specification). =
The Gateway has to suitably interpret the S/MIME message</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; build an =
equivalent X.400 message with the CMS object solely being the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">content </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; of the X.400 =
message and vice versa for a message that comes from X.400</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">side.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; To be more precise =
X.400 MTA's functionality is to just transfer message</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">based</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; on the information =
available in the P1 envelope, without bothering about</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; syntax of the =
content. Is my assumption correct?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">c) X.420 (1999) recomendations defines =
PKCS7 as one of standard IPM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">bodyparts.Since</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; CMS is derived =
from or is a subset of PKCS7, can it be used to convey</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">CMS object </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; into X.400 from =
Internet?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I am using Microsoft Exchange Server =
connected to our X.400 MTA via the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Exchange </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">X.400 connector for testing purposes. =
We use Exchange server as a S/MIME UA.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">The</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">test setup is&nbsp; briefly as =
follows:</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Internet &lt;------&gt; SMTP Gateway =
&lt;----&gt; X.400 MTA &lt;-------------------------&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Exchange MTA </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"Arial"=
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
(Digital)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; X.400 =
connector</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">( Microsoft)</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Our Gateway follows the RFCs MIME, MIXER and creates an =
IPM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">accordingly in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">X.400. We have our own MTA which =
supports IPM( 1984 and 1988), IPN, EDI</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">messages.</FONT>
</P>
<BR>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Can anyone clarify my doubts/assumptions.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Nandiprasad J.M</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C0B209.BA4B22F0--


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id DAA18197 for ietf-smime-bks; Wed, 21 Mar 2001 03:34:13 -0800 (PST)
Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA18193 for <[e-mail]>; Wed, 21 Mar 2001 03:34:12 -0800 (PST)
Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id C12E3C30C; Wed, 21 Mar 2001 06:33:42 -0500 (EST)
Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 8A86EC385 for <[e-mail]>; Wed, 21 Mar 2001 06:33:42 -0500 (EST)
Received: by mailrelay01.cce.cpqcorp.net (Postfix, from userid 12345) id 4EB902FA; Wed, 21 Mar 2001 05:33:42 -0600 (CST)
Received: from diexch01.xko.dec.com (diexch01.xko.dec.com [16.168.64.114]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id F249E2B8 for <[e-mail]>; Wed, 21 Mar 2001 05:33:39 -0600 (CST)
Received: by diexch01.xko.dec.com with Internet Mail Service (5.5.2650.21) id <G07QFFFM>; Wed, 21 Mar 2001 17:04:56 +0530
Message-ID: <[e-mail]>
From: "Prasad, Nandi" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: S/MIME support in SMTP Gateway
Date: Wed, 21 Mar 2001 17:04:55 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
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>

Hello everybody

	I am working in a project which invloves S/MIME support in the SMTP
Gateway which acts as a gateway between Internet and X.400 world. Our
Gateway
is connected to X.400 MTA and converts any Internet message (text/MIME) onto

equivalent X.400 IPM and vice versa.

	At this point of time what we expect to do is convert/tunnel the
incoming 
S/MIME message from Internet into X.400.I have gone through many documents 
but haven't found any clear information about S/MIME support in X.400. The
current 
drafts "draft-ietf-smime-x400transport" and  "draft-ietf-smime-x400wrap"
gives me 
some information about transporting S/MIME in X.400.

	I have some queries about them and they are as follows:

a) What I understand about the "draft-ietf-smime-x400transport" is that one 
    has to transport the CMS object as a seperate content with the
"content-type" 
    field pf the P1 envelope containing OIDs {1 2 840 113549 1 7 1}  ( if
the CMS
    object has a MIME wrapper) or {1 2 840 113549 1 9 16 1 6} (If the CMS
object 
    doesn't have a MIME wrapper).

b) Coming to the transport of S/MIME messages from Internet to X.400 via a
SMTP 
    gateway,  I assume that the format of the message that arrives at the
Gateway 
    from Internet will be according to RFC 2633( i.e S/MIME Version 3
Message 
    specification). The Gateway has to suitably interpret the S/MIME message
and 
    build an equivalent X.400 message with the CMS object solely being the
content 
    of the X.400 message and vice versa for a message that comes from X.400
side.
    To be more precise X.400 MTA's functionality is to just transfer message
based
    on the information available in the P1 envelope, without bothering about
the 
    syntax of the content. Is my assumption correct?

c) X.420 (1999) recomendations defines PKCS7 as one of standard IPM
bodyparts.Since
    CMS is derived from or is a subset of PKCS7, can it be used to convey
CMS object 
    into X.400 from Internet?

I am using Microsoft Exchange Server connected to our X.400 MTA via the
Exchange 
X.400 connector for testing purposes. We use Exchange server as a S/MIME UA.
The
test setup is  briefly as follows:


Internet <------> SMTP Gateway <----> X.400 MTA <------------------------->
Exchange MTA 
				      (Digital)          X.400 connector
( Microsoft)

	Our Gateway follows the RFCs MIME, MIXER and creates an IPM
accordingly in
X.400. We have our own MTA which supports IPM( 1984 and 1988), IPN, EDI
messages.


	Can anyone clarify my doubts/assumptions.

Regards
Nandiprasad J.M



Received: by above.proper.com (8.9.3/8.9.3) id HAA22187 for ietf-smime-bks; Tue, 20 Mar 2001 07:13:03 -0800 (PST)
Received: from guard.arkoon.net (ALyon-201-1-1-34.abo.wanadoo.fr [193.251.84.34]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA22181 for <[e-mail]>; Tue, 20 Mar 2001 07:12:58 -0800 (PST)
From: [e-mail]
Received: (from uucp@localhost) by guard.arkoon.net (8.10.2/8.10.2) id f2KFF9p05262 for <[e-mail]>; Tue, 20 Mar 2001 16:15:09 +0100
Received: from UNKNOWN(192.168.100.2), claiming to be "arkoon-mail.arkoon.net" via SMTP by guard.arkoon.in, id smtpdPE8sas; Tue Mar 20 16:15:04 2001
Received: by arkoon-mail.arkoon.net(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999))  id C1256A15.00532B64 ; Tue, 20 Mar 2001 16:08:25 +0100
X-Lotus-FromDomain: ARKOON
To: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 20 Mar 2001 16:08:21 +0100
Subject: About Mime Format
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>

Sir,

I am working on a new prg to analyze mails that were "encoded" in Mime format
and have two questions about this one.


Well ... the first :

In the case of Message Media Type, External-Body Subtype I don't understand very
well ftp, tftp and anon-ftp access types.

     Is the file (which is indicated with Name, Site parameters) present in the
mail ? Who executed ftp command, is man who send the mail or man who received it
?

====================================

Second and last question :

Always in case of Message Media Type, External-Body Subtype but Mail-Server
access-type.

     When and how this command can be used ? I don't know how I can used this
one with my mail server.

====================================

Thank to your answers.

     Lionel.




Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id VAA21302 for ietf-smime-bks; Sun, 18 Mar 2001 21:09:47 -0800 (PST)
Received: from mail.atmnet.co.kr (server.atmnet.co.kr [203.228.196.11]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA21285; Sun, 18 Mar 2001 21:09:44 -0800 (PST)
From: [e-mail]
Received: from 208.170.55.221 (dialup-221-isdn.cwtel.com [208.170.55.221]) by mail.atmnet.co.kr (8.9.3/8.9.2) with SMTP id OAA12764; Mon, 19 Mar 2001 14:06:24 +0900
Message-Id: <[e-mail]>
To: 
Subject: DAMAGED GEAR
Date: Sun, 18 Mar 01 23:57:58 Eastern Standard Time
Reply-To: [e-mail]
X-Priority: 1
X-MSMailPriority: High
Importance: High
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_018C_01BD9940.715D52A0"
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_018C_01BD9940.715D52A0
Content-Type: text/html;

<HTML>
<BODY>
<html>

<body bgcolor="#000000" MARGINWIDTH="0" LEFTMARGIN="0" RIGHTMARGIN="0">
&nbsp;
<table ALIGN=LEFT BORDER=0 WIDTH="100%" >
<tr>
<td><img SRC="http://www.sosworldwide.com/images/homelogo.gif" ALT="Speed of Sound" ></td>

<td>
<table ALIGN=LEFT BORDER=0 CELLSPACING=0 CELLPADDING=0 >
<tr>
<td COLSPAN="7"><b><font face="verdana, ariel, helvetica"><font color="#FFFFFF"><font size=-1>THE
SHORTEST DISTANCE BETWEEN SERVICE AND RELIABILITY</font></font></font></b></td>
</tr>

<tr>
<td COLSPAN="7"><img SRC="http://www.sosworldwide.com/images/spacer.gif" ALT="tour" height=6 width=1></td>
</tr>

<tr>
<td><a href="http://www.sosworldwide.com/index.html"><img SRC="http://www.sosworldwide.com/nav/home.gif" NAME="home" ALT="tour" BORDER=0 height=22 width=49></a></td>

<td><a href="http://www.sosworldwide.com/about.html"><img SRC="http://www.sosworldwide.com/nav/about.gif" NAME="about" ALT="tour" BORDER=0 height=22 width=76></a></td>

<td><a href="http://www.sosworldwide.com/services.html"><img SRC="http://www.sosworldwide.com/nav/services.gif" NAME="services" ALT="tour" BORDER=0 height=22 width=74></a></td>

<td><a href="http://www.sosworldwide.com/clients.html"><img SRC="http://www.sosworldwide.com/nav/clients.gif" NAME="clients" ALT="tour" BORDER=0 height=22 width=64></a></td>

<td><a href="http://www.sosworldwide.com/quote.html"><img SRC="http://www.sosworldwide.com/nav/onlinequote.gif" NAME="onlinequote" ALT="tour" BORDER=0 height=22 width=98></a></td>

<td><a href="http://www.sosworldwide.com/resources.html"><img SRC="http://www.sosworldwide.com/nav/resources.gif" NAME="resources" ALT="tour" BORDER=0 height=22 width=90></a></td>

<td><a href="http://www.sosworldwide.com/contact.html"><img SRC="http://www.sosworldwide.com/nav/contact.gif" NAME="contact" ALT="tour" BORDER=0 height=22 width=69></a></td>
</tr>
</table>
</td>
</tr>

<tr>
<td COLSPAN="2">
<table BORDER=0 CELLSPACING=0 CELLPADDING=0 WIDTH="100%" HEIGHT="300" BACKGROUND="http://www.sosworldwide.com/images/bkg2.gif" >
<tr>
<td ALIGN=CENTER><b><font face="verdana, ariel, helvetica"><font color="#FFFFFF"><font size=+0>WELCOME
TO SPEED OF SOUND</font></font></font></b>
<br><b><font face="verdana, ariel, helvetica"><font color="#FFFFFF"><font size=+0>THE
BEST IN WORLD WIDE FORWARDING</font></font></font></b>
<br>&nbsp;
<p><font face="verdana, ariel, helvetica"><font color="#FFFFFF"><font size=-1>Speed
of Sound is a full service freight forwarder specializing in the field
of</font></font></font>
<br><font face="verdana, ariel, helvetica"><font color="#FFFFFF"><font size=-1>production
and tour equipment. Our staff is comprised of the finest and most</font></font></font>
<br><font face="verdana, ariel, helvetica"><font color="#FFFFFF"><font size=-1>experienced
tour managers, production managers and freight specialists in the</font></font></font>
<br><font face="verdana, ariel, helvetica"><font color="#FFFFFF"><font size=-1>industry.
Our background assures our clients of a customized package contoured</font></font></font>
<br><font face="verdana, ariel, helvetica"><font color="#FFFFFF"><font size=-1>for
the sensitivity of your equipment, time constraints and budget</font></font></font>
<br><font face="verdana, ariel, helvetica"><font color="#FFFFFF"><font size=-1>requirements.</font></font></font></td>
</tr>

<tr>
<td ALIGN=CENTER><img SRC="http://www.sosworldwide.com/images/long.jpg" ALT="tour" >
<br>&nbsp;</td>
</tr>
</table>

<center><font face="verdana, ariel, helvetica"><font color="#FFFFFF"><font size=-1>Call
us for a Quote on your next Tour or Shipment!</font></font></font>
<br><font face="verdana, ariel, helvetica"><font color="#FFFFFF"><font size=-1>East
Coast 1-800-SOS-4699 West Coast 1-800-SOS-8609</font></font></font><font face="verdana, ariel, helvetica"><font color="#FFFFFF"><font size=-1></font></font></font>
<p><font face="verdana, ariel, helvetica"><font color="#FFFFFF"><font size=-2>If
you wish to be removed from our mailing list, simply reply to [e-mail]&nbsp;</font></font></font>
<br><font face="verdana, ariel, helvetica"><font color="#FFFFFF"><font size=-2>with
remove in the subject line.&nbsp; Your request will be processed within
48 hours.&nbsp;</font></font></font></center>
</td>
</tr>
</table>

</body>
</html>



















<html>

<body bgcolor="#000000" MARGINWIDTH="0" LEFTMARGIN="0" RIGHTMARGIN="0">
&nbsp;
<table ALIGN=LEFT BORDER=0 WIDTH="100%" >








</BODY></HTML>




Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id VAA15224 for ietf-smime-bks; Sat, 17 Mar 2001 21:02:42 -0800 (PST)
Received: from romeo.rtfm.com (speedy.rtfm.com [198.144.206.141] (may be forged)) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA15218 for <[e-mail]>; Sat, 17 Mar 2001 21:02:39 -0800 (PST)
Received: from rtfm.com (localhost [127.0.0.1]) by romeo.rtfm.com (8.9.3/8.6.4) with ESMTP id VAA01053 for <[e-mail]>; Sat, 17 Mar 2001 21:07:52 -0800 (PST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Million Message Attack draft
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Sat, 17 Mar 2001 21:07:52 -0800
From: Eric Rescorla <[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>

Now that RSA is once again going to be a (the?) mandatory CMS
cipher, there's been some concern about whether it was possible
to mount a Million Message attack on CMS. The following draft
describes the situation and the appropriate countermeasures
(if any). 
 
I'll be submitting this as an I-D but I wanted to get it out before
Minneapolis (barely).

-Ekr








INTERNET-DRAFT                                               E. Rescorla
<draft-ietf-smime-pkcs1-01.txt>                              RTFM, Inc.
                                    (March 2000 (Expires September 2001)

              Preventing the Million Message Attack on CMS

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference mate-
   rial or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
   ftp.isi.edu (US West Coast).

1.  Introduction

   When data is encrypted using RSA it must be padded out to the length
   of the modulus--typically 512 to 2048 bits.  he most popular tech-
   nique for doing this is described in [PKCS-1]. However, in 1998 Ble-
   ichenbacher described an adaptive chosen ciphertext attack on SSL
   [MMA]. This attack, called the Million Message Attack, allowed the
   recovery of a single PKCS-1 encrypted block, provided that the
   attacker could convince the receiver to act as a particular kind of
   oracle. The MMA is also possible against [CMS]. The CMS implementa-
   tions most likely to be targets for the MMA are automated servers
   such as mailing list agents, which will automatically respond to a
   large number of messages. This document describes a strategy for
   resisting such attacks.

2.  Overview of PKCS-1

   The first stage in RSA encryption is to map the message to be
   encrypted (in CMS a symmetric Content Encryption Key (CEK)) into an
   integer of the same order as (but less than) the RSA modulus of the
   recipient's public key (typically somewhere between 512 and 2048
   bits). PKCS-1 describes the most common procedure for this transfor-
   mation.



Rescorla                                                         [Page 1]Internet-Draft     Security Considerations Guidelines     


   We start with an "encryption block" of the same length as the modu-
   lus. The rightmost bits of the string are set to the message to be
   encrypted.  The first two bytes are a zero byte and a "block type"
   byte. For encryption the block type is 2. The remaining bytes are
   used as padding. The padding is constructed by generating a series of
   non-zero random bytes. The last padding byte is zero, which allows
   the padding to be distinguished from the message.

     |--------------------------------------------------------|
     | 0 | 2 | Nonzero random bytes | 0 |      Message        |
     |--------------------------------------------------------|

   Once the block has been formatted, the sender must then convert the
   block into an integer. This is done by treating the block as an inte-
   ger in big-endian form. Thus, the resulting number is less than the
   modulus (because the first byte is zero), but of more or less the
   same order (because the second byte is 2).

   In CMS, the message is always a randomly generated symmetric content
   encryption key (CEK). Depending on the cipher being used it might be
   anywhere from 64 to 256 bytes.

   There must be at least 8 bytes of non-random. The padding prevents an
   attacker from verifying guesses about the encrypted message.  Imagine
   that the attacker wishes to determine whether or not two RSA-
   encrypted keys are the same. Because there are at least 2^64 differ-
   ent padding value with high probability two encryptions of the same
   message will be different. The padding also prevents the attacker
   from verifying guessed CEKs by trial-encrypting them with the recipi-
   ent's RSA key since he must try each potential pad for every guess.
   Note that a lower cost attack would be to exhaustively search the CEK
   space by trial-decrypting the content and examining the plaintext to
   see if it appears reasonable.

2.1.  The Million Message Attack

   The purpose of the Million Message Attack (MMA) is to recover a sin-
   gle plaintext given the ciphertext. The attacker first captures the
   ciphertext in transit and then uses the recipient as an oracle to
   recover the plaintext by sending transformed versions of the cipher-
   text and observing the recipient's response.

   Call the ciphertext C. The attacker then generates a series of inte-
   gers S and computes C'=C(S^e) mod n. Upon decryption, C' produces a
   corresponding plaintext M'. Most M's will appear to be garbage but
   some M's (about one in 2^16) will have the correct first two bytes 00
   02 and thus appear to be correctly PKCS-1 formatted. The attack pro-
   ceeds by finding a sequence of values S such that the resulting M' is



Rescorla                                                         [Page 2]Internet-Draft     Security Considerations Guidelines     


   correctly PKCS-1 formatted. This information can be used to discover
   M. Operationally, this attack usually requires about 2^20 messages
   and responses. Details can be found in [MMA].

2.2.  Applicability


   Since the MMA requires so many messages, it must be mounted against a
   victim who is willing to process a large number of messages. In prac-
   tice, no human is willing to read this many messages and so the MMA
   can only be mounted against an automated victim.

   The MMA also requires that the attacker be able to distinguish cases
   where M' was PKCS-1 formatted from cases where it was not.  In the
   case of CMS the attacker will be sending CMS messages with M' replac-
   ing the wrapped CEK. Thus, there are five possibilities:

   1. M' is improperly formatted.
   2. M' is properly formatted but the CEK is prima facie bogus
   (wrong length, etc.)
   3. M' is properly formatted and the CEK appears OK. A signature
   or MAC is present so integrity checking fails.
   4. M' is properly formatted and no integrity check is applied.
   In this case there is some possibility (approximately 1/8) that
   the CBC padding block will verify correctly. The message will
   appear OK at the CMS level but will be bogus at the application
   level.
   5. M' is properly formatted and the resulting CEK is correct.
   This is extremely improbable but not impossible.

   The MMA requires the attacker to be able to distinguish case 1 from
   cases 2-4. (He can always distinguish case 5, of course). This might
   happen if the victim returned different errors for each case. The
   attacker might also be able to distinguish these cases based on tim-
   ing--decrypting the message and verifying the signature takes some
   time.  If the victim responds uniformly to all four errors then no
   attack is possible.

2.3.  Countermeasures

2.3.1.  Careful Checking

   Even without countermeasures, sufficiently careful checking can go
   quite a long way to mitigating the success of the MMA.  If the
   receiving implementation also checks the length of the CEK and the
   parity bits (if available) AND responds identically to all such
   errors, the chances of a given M' being correctly formatted are sub-
   stantially decreased. This increases the number of probe messages



Rescorla                                                         [Page 3]Internet-Draft     Security Considerations Guidelines     


   required to recover M. However, this sort of checking only increases
   the workfactor and does not eliminate the attack entirely because
   some messages will still be correctly formatted up to the point of
   keylength. However, the combination of all three kinds of checking
   (padding, length, parity bits) increases the number of messages to
   the point where the attack is impractical.

2.3.2.  Random Filling

   The simplest countermeasure is to treat misformatted messages as if
   they were correctly PKCS-1 formatted. When the victim detects an
   incorrectly formatted message, instead of returning an error he sub-
   stitutes a randomly generated message. In CMS, since the message is
   always a wrapped content encryption key (CEK) the victm should simply
   substitute a randomly generated CEK of appropriate length and con-
   tinue. Eventually this will result in a decryption or signature veri-
   fication error but this is exactly what would have happened if M'
   happened to be correctly formatted. Note that the timing behavior
   will also identical.

   In a layered implementation it's quite possible that the PKCS-1 check
   occurs at a point in the code where the length of the expected CEK is
   not known. In that case the implementation must ensure that bad
   PKCS-1 padding and ok-looking PKCS-1 padding with an incorrect length
   CEK behave the same. An easy way to do this is to also randomize CEKs
   that are of the wrong length or otherwise improperly formatted.

   Note: It is a mistake to use a fixed CEK because the attacker could
   then produce a CMS message encrypted with that CEK. This message
   would decrypt correctly, thus allowing the attacker to determine that
   the PKCS-1 formatting was incorrect.  In fact, the randomly generated
   CEK should be cryptographically random, thus preventing the attacker
   from guessing the next "random" CEK to be used.

2.3.3.  OAEP

   Optimal Asymmetric Encryption Padding (OAEP) [OAEP, PKCS1v2] is
   another technique for padding a message into an RSA encryption block.
   Implementations using OAEP are not susceptible to the MMA. However,
   OAEP is incompatible with PKCS-1. Implementations of S/MIME and CMS
   must therefore continue to use PKCS-1 for the foreseable future.

2.4.  Security Considerations

   This entire document describes how to avoid a certain class of
   attacks when performing PKCS-1 decryption with RSA.





Rescorla                                                         [Page 4]Internet-Draft     Security Considerations Guidelines     


References
   [PKCS-1]
   [MMA]
   [CMS]

Author's Address
Eric Rescorla <[e-mail]>
RTFM, Inc.
2439 Alvin Drive
Mountain View, CA 94043
Phone: [phone]








































Rescorla                                                         [Page 5]Internet-Draft     Security Considerations Guidelines     


                           Table of Contents


1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .   1
2. Overview of PKCS-1  . . . . . . . . . . . . . . . . . . . . . . .   1
2.1. The Million Message Attack  . . . . . . . . . . . . . . . . . .   2
2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . .   3
2.3. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . .   3
2.3.1. Careful Checking  . . . . . . . . . . . . . . . . . . . . . .   3
2.3.2. Random Filling  . . . . . . . . . . . . . . . . . . . . . . .   4
2.3.3. OAEP  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
2.4. Security Considerations . . . . . . . . . . . . . . . . . . . .   4
2.4. References  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . .   5







































Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA19019 for ietf-smime-bks; Sat, 17 Mar 2001 13:01:18 -0800 (PST)
Received: from lun.co.jp ([202.229.220.192]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA19012 for <[e-mail]>; Sat, 17 Mar 2001 13:01:11 -0800 (PST)
Received: from host (02-094.044.popsite.net [64.24.247.94]) by lun.co.jp (8.8.5+2.7Wbeta5/3.5Wbeta:04/10/97) with ESMTP id FAA14987; Sun, 18 Mar 2001 05:50:33 +0900 (JST)
Message-Id: <[e-mail]>
From: "Neil P. Meyer" <[e-mail]>
Subject: Compared #563A
To: [e-mail]
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3
Mime-Version: 1.0
Date: Sat, 17 Mar 2001 13:32:23 -0500
Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0"
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>

This is a MIME Message

------=_NextPart_000_007F_01BDF6C7.FABAC1B0
Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0"

------=_NextPart_001_0080_01BDF6C7.FABAC1B0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

***** This is an HTML Message ! *****


------=_NextPart_001_0080_01BDF6C7.FABAC1B0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dwindows-=
1252">
<meta name=3D"GENERATOR" content=3D"Microsoft FrontPage 4=2E0">
<meta name=3D"ProgId" content=3D"FrontPage=2EEditor=2EDocument">
<title>FREE Computer With Merchant Account Setup</title>
</head>

<body>

<center>
<p><b>COMPLETE CREDIT CARD PROCESSING SYSTEMS FOR YOUR BUSINESS=2E INTERNE=
T -  HOME
BASED -  MAIL ORDER -  PHONE ORDER</b></p>
<p><b>Do you accept credit cards? Your competition does!</b></p>
<p>&nbsp;</p>
<p>Everyone Approved - Credit Problems OK!<br>
Approval in less than 24 hours!<br>
Increase your sales by 300%<br>
Start Accepting Credit Cards on your website!<br>
Free Information, No Risk, 100% confidential=2E<br>
Your name and information will not be sold to thrid parties!<br>
Home Businesses OK!  Phone/Mail Order OK!<br>
No Application Fee, No Setup Fee!<br>
Close More Impulse Sales!<br>
<br>
</p>
<div align=3D"center">
  <table border=3D"0" cellspacing=3D"0" width=3D"85%">
    <tr>
      <td width=3D"100%">
        <p align=3D"center"><b><font face=3D"Times New Roman" size=3D"5" c=
olor=3D"#CC0000">Everyone Approved!</font></b></p>
        <p><b><font face=3D"Times New Roman"> Good Credit or Bad!&nbsp; To=
 apply today, please fill out
        the express form below=2E It
contains all the information we need to get your account approved=2E For a=
rea's
that do not apply to you please put &quot;n/a&quot; in the box=2E<br>
<br>
Upon receipt, we'll fax you with all of the all Bank Card Application
documents necessary to establish your Merchant Account=2E Once returned we=
 can
have your account approved within 24 hours=2E<br>&nbsp;</font></b>
        </p>
      </td>
    </tr>
  </table>
</div>
<table border=3D"10" cols=3D"3" width=3D"385">
  <tbody>
    <tr>
      <td align=3D"center" bgColor=3D"#990000" width=3D"119"><b><font colo=
r=3D"#ffff00" face=3D"Arial,Helvetica" size=3D"3">Service</font></b></td>
      <td align=3D"center" bgColor=3D"#990000" width=3D"160"><b><font colo=
r=3D"#ffff00" face=3D"Arial,Helvetica" size=3D"3">Industry
        Standard</font></b></td>
      <td align=3D"center" bgColor=3D"#990000" width=3D"66">
        <p align=3D"center"><b><font color=3D"#ffff00" face=3D"Arial,Helve=
tica" size=3D"3">US</font></b></p>
      </td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">Site
        Inspection</font></b></td>
      <td align=3D"middle" width=3D"160"><b><font size=3D"2">$50 - $75</fo=
nt></b></td>
      <td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica"=
 size=3D"2">FREE</font></b></td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">Shipping</font></b></td>
      <td align=3D"middle" width=3D"160"><b><font size=3D"2">$50 - $75</fo=
nt></b></td>
      <td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica"=
 size=3D"2">FREE</font></b></td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">Warranty</font></b></td>
      <td align=3D"middle" width=3D"160"><b><font size=3D"2">$10 Per Month=
</font></b></td>
      <td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica"=
 size=3D"2">FREE</font></b></td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">Sales
        Receipts</font></b></td>
      <td align=3D"middle" width=3D"160"><b><font size=3D"2">$10 - $50&nbs=
p;</font></b></td>
      <td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica"=
 size=3D"2">FREE</font></b></td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">Fraud
        Screening</font></b></td>
      </center>
    <td align=3D"middle" width=3D"160">
      <p align=3D"left"><font size=3D"2"><b>$=2E50 - $1=2E00</b><br>
      <b>Per Transaction</b></font></p>
    </td>
<center>
<td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica" size=3D=
"2">FREE</font></b></td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">Amex Set
        Up</font></b></td>
      <td align=3D"middle" width=3D"160"><b><font size=3D"2">$50 - $75</fo=
nt></b></td>
      <td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica"=
 size=3D"2">FREE</font></b></td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">24 Hour&nbsp;Help
        Line</font></b></td>
      <td align=3D"middle" width=3D"160"><b><font size=3D"2">$10 Month</fo=
nt></b></td>
      <td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica"=
 size=3D"2">FREE</font></b></td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">Security
        Bond</font></b></td>
      <td align=3D"middle" width=3D"160"><font size=3D"2"><b>$5000- $10,00=
0</b><br>
        <b>Or More</b></font></td>
      <td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica"=
 size=3D"2">NONE</font></b></td>
    </tr>
  </tbody>
</table><p>
<div align=3D"center">
  <table border=3D"0" cellspacing=3D"0" width=3D"85%">
    <tr>
      <td width=3D"100%">
        <p><font face=3D"Arial,Helvetica" size=3D"2"><b>This is a <font co=
lor=3D"#3333ff">No
        Obligation Qualification Form</font> and is your first step to<fon=
t color=3D"#cc0000">
        accepting credit cards=2E</font> By filling out this form you will=
 <font color=3D"#3333ff">&quot;not
        enter&quot;</font> in to any <font color=3D"#006600">obligations o=
r
        contracts </font>with us=2E We will use it to determine the best p=
rogram
        to offer you based on the information you provide=2E You will be c=
ontacted by one of our representatives within 1-2 business days to go over =
the rest of your account set up=2E</b></font>
        <p align=3D"center"><font face=3D"Arial,Helvetica" size=3D"2"><b><=
font color=3D"#cc0000">Note:</font>&nbsp;
        All Information Provided To Us <font color=3D"#cc0000">Will Remain=
 100%
        Confidential</font>
        !!&nbsp;</b></font></td>
    </tr>
  </table>
</div>
<table border=3D"0">
  <tbody>
    <tr>
      <td width=3D"100%">
        <p align=3D"center"><b><font color=3D"#000099" face=3D"arial" size=
=3D"+2">Apply
        Free With No Risk!</font></b></p>
      </td>
    </tr>
  </tbody>
</table>
  </center>
</form>
<div align=3D"left">
  <table border=3D"0" width=3D"95%">
    <tr>
      <td width=3D"100%">
        <p align=3D"center"><b><i><font size=3D"2" color=3D"#CC0000">Pleas=
e fill out the
        express application form completely=2E<br>Incomplete information m=
ay prevent us from properly
        processing your application=2E</font></i></b></p>
      </td>
    </tr>
  </table>
</div>
<form name=3D"form"
  method=3D"post"
  action=3D"mailto:bel892@verizonmail=2Ecom?SUBJECT=3DMerchant Form"
  enctype=3D"text/plain"
  
 
 <tr>
<div align=3D"left">
  <table border=3D"0" width=3D"95%">
    <tr>
      <td width=3D"61%" align=3D"right"><font size=3D"2"><b>Your Full Emai=
l Address:</b><br>
        <font color=3D"#ff0000">be sure to use your full address </font>(i=
=2Ee=2E<font color=3D"#ff0000">
        </font>user@domain=2Ecom)</font></td>
      <td width=3D"39%" align=3D"center"><input type=3D"text" name=3D"user=
_email" size=3D"29"></td>
    </tr>
    <tr>
      <td width=3D"61%" align=3D"right"><b><font size=3D"2">Your Name:</fo=
nt></b></td>
      <td width=3D"39%" align=3D"center"><input type=3D"text" name=3D"Appl=
icant_Name" size=3D"29"></td>
    </tr>
    <tr>
      <td width=3D"61%" align=3D"right"><b><font size=3D"2">Business Name:=
</font></b></td>
      <td width=3D"39%" align=3D"center"><input type=3D"text" name=3D"Busi=
ness_Name" size=3D"29"></td>
    </tr>
    <tr>
      <td width=3D"61%" align=3D"right"><b><font size=3D"2">Business Phone=
 Number:</font></b></td>
      <td width=3D"39%" align=3D"center"><input type=3D"text" name=3D"Busi=
ness_Phone" size=3D"29"></td>
    </tr>
    <tr>
      <td width=3D"61%" align=3D"right"><b><font size=3D"2">Home Phone Num=
ber:</font></b></td>
      <td width=3D"39%" align=3D"center"><input type=3D"text" name=3D"Home=
Phone" size=3D"29"></td>
    </tr>
    <tr>
      <td width=3D"61%" align=3D"right"><b><font size=3D"2">Type of Busine=
ss:</font></b></td>
      <td width=3D"39%">
        <div align=3D"left">
          <table border=3D"0" width=3D"95%">
            <tr>
              <td width=3D"12%" align=3D"center"><input type=3D"radio" val=
ue=3D"retail" name=3D"Type_Business"></td>
              <td width=3D"88%"><font size=3D"2"><b>Retail Business</b></f=
ont></td>
            </tr>
            <tr>
              <td width=3D"12%" align=3D"center"><input type=3D"radio" val=
ue=3D"mailorder" name=3D"Type_Business"></td>
              <td width=3D"88%"><font size=3D"2"><b>Mail Order Business</b=
></font></td>
            </tr>
            <tr>
              <td width=3D"12%" align=3D"center"><input type=3D"radio" val=
ue=3D"internet" name=3D"Type_Business"></td>
              <td width=3D"88%"><font size=3D"2"><b>Internet Based Busines=
s</b></font></td>
            </tr>
          </table>
        </div>
      </td>
    </tr>
    <tr>
      <td width=3D"61%" align=3D"right"><b><font size=3D"2">Personal Credi=
t Rating:</font></b></td>
      <td width=3D"39%">
        <div align=3D"left">
          <table border=3D"0" width=3D"95%">
            <tr>
              <td width=3D"12%" align=3D"center"><input type=3D"radio" val=
ue=3D"excellent" name=3D"Credit_Rank"></td>
              <td width=3D"88%">Excellent</td>
            </tr>
            <tr>
              <td width=3D"12%" align=3D"center"><input type=3D"radio" val=
ue=3D"good" name=3D"Credit_Rank"></td>
              <td width=3D"88%">Good</td>
            </tr>
            <tr>
              <td width=3D"12%" align=3D"center"><input type=3D"radio" val=
ue=3D"fair" name=3D"Credit_Rank"></td>
              <td width=3D"88%">Fair</td>
            </tr>
            <tr>
              <td width=3D"12%" align=3D"center"><input type=3D"radio" val=
ue=3D"poor" name=3D"Credit_Rank"></td>
              <td width=3D"88%">Poor</td>
            </tr>
          </table>
        </div>
      </td>
    </tr>
    <tr>
      <td width=3D"61%" align=3D"right"><b><font size=3D"2">How Soon Would=
 You Like a Merchant
        Account?</font></b></td>
      <td width=3D"39%">
        <p align=3D"center"><input type=3D"text" name=3D"How_Soon" size=3D=
"29"></p>
      </td>
    </tr>
    <tr>
      <td width=3D"100%" colspan=3D"2">
        <div align=3D"center">
          <center>
          <table border=3D"0" width=3D"13%">
            <tr>
              <td width=3D"100%">
                <p align=3D"center"><input type=3D"submit" value=3D"Submit=
" name=3D"B1"></td>
            </tr>
          </table>
          </center>
        </div>
      </td></form>
    </tr>
  </table>
</div><br>
<div align=3D"center">
  <center>
  <table border=3D"3" cellspacing=3D"0" width=3D"85%" bgcolor=3D"#E8E8E8" =
bordercolor=3D"#C0C0C0">
    <tr>
      <td width=3D"100%" bgcolor=3D"#E8E8E8"><font size=3D"2"><b>Your info=
rmation is confidential, it will not be sold or used for any other purpose,=
 and you are under no obligation=2E
        Your information will be used solely for the purpose of evaluating=
 your business or website for a merchant account so that you may begin acce=
pting credit card payments=2E</b></font>
      </td>
    </tr>
  </table>
  </center>
</div>

</form>

<p align=3D"center">
<br><b><font size=3D"3" color=3D"#FF0000">List
 Removal/OPT-OUT Option</font></b>
 <br><b><font color=3D"#000000"><font size=3D-1><a
 href=3D"mailto:tpmk9@eudoramail=2Ecom?subject=3Dremove">Click
 Here</a></font></font></b>

</body>


</html>


------=_NextPart_001_0080_01BDF6C7.FABAC1B0--

------=_NextPart_000_007F_01BDF6C7.FABAC1B0--





Received: by above.proper.com (8.9.3/8.9.3) id HAA11273 for ietf-smime-bks; Fri, 9 Mar 2001 07:50:25 -0800 (PST)
Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by above.proper.com (8.9.3/8.9.3) with SMTP id HAA11267 for <[e-mail]>; Fri, 9 Mar 2001 07:50:24 -0800 (PST)
Received: (qmail 35740 invoked from network); 9 Mar 2001 15:50:24 -0000
Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by 172.16.1.1 with SMTP; 9 Mar 2001 15:50:24 -0000
Received: (qmail 6553 invoked from network); 9 Mar 2001 15:50:23 -0000
Received: from mnystrom-lap.d.dynas.se (HELO mnystrom-lap) (172.16.13.246) by spirit.dynas.se with SMTP; 9 Mar 2001 15:50:23 -0000
Date: Fri, 9 Mar 2001 16:51:01 +0100 (W. Europe Standard Time)
From: Magnus Nystrom <[e-mail]>
Reply-To: <[e-mail]>
To: <[e-mail]>
Subject: RE: WG Last Call:draft-ietf-smime-rcek-01.txt 
Message-ID: <Pine.WNT.4.31.0103091643570.696-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>

Stephen,

I have two comments related to the discussion of the above mentioned
draft,

For the id-cek-maxDecrypts attribute, since it is an unprotected
attribute, there is no protection against anyone modifying its
value. It therefore seems as if it could be an advantage to restrain
possible values already in the specification. At the very least
I suggest it to be specified as INTEGER (1..MAX), so that recipients
won't be confused by negative values. <MAX> could be replaced by
something less, of course.

For the X9.63 KDF, I support using it instead of the PKCS #5 KDF,
since it is intended for cases like this and PKCS #5 really is
intended for something else. But for the algorithm itself, I think it
would be better if the algorithm actually was included in the
document, especially since it is quite short/compact.

-- Magnus
Magnus Nystrom
RSA Security





Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id EAA29081 for ietf-smime-bks; Fri, 9 Mar 2001 04:37:24 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA29072 for <[e-mail]>; Fri, 9 Mar 2001 04:37:22 -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 HAA11835; Fri, 9 Mar 2001 07:37:21 -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-symkeydist-03.txt
Date: Fri, 09 Mar 2001 07:37:21 -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 Symmetric Key Distribution
	Author(s)	: S. Turner
	Filename	: draft-ietf-smime-symkeydist-03.txt
	Pages		: 72
	Date		: 08-Mar-01
	
This document describes a mechanism to manage (i.e., setup,
distribute, and rekey) keys used with symmetric cryptographic
algorithms. Also defined herein is a mechanism to organize users
into groups to support distribution of encrypted content using
symmetric cryptographic algorithms. The mechanisms use the
Cryptographic Message Syntax (CMS) protocol [2] and Certificate
Management Message over CMS (CMC) protocol [3] to manage the
symmetric keys. Any member of the group can then later use this
distributed shared key to decrypt other CMS encrypted objects with
the symmetric key. This mechanism has been developed to support
S/MIME Mail List Agents (MLAs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-symkeydist-03.txt

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-symkeydist-03.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-symkeydist-03.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-symkeydist-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-symkeydist-03.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.9.3/8.9.3) id NAA27671 for ietf-smime-bks; Thu, 8 Mar 2001 13:06:15 -0800 (PST)
Received: from mail.ca.certicom.com (ip6.certicom.com [209.121.99.6] (may be forged)) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA27661 for <[e-mail]>; Thu, 8 Mar 2001 13:06:14 -0800 (PST)
Received: from smtpmail.certicom.com (domino2.certicom.com [10.0.1.25]) by mail.ca.certicom.com (8.9.3/8.9.3) with SMTP id QAA25045; Thu, 8 Mar 2001 16:00:00 -0500 (EST)
Received: by smtpmail.certicom.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256A09.0073D4EC ; Thu, 8 Mar 2001 16:05:11 -0500
X-Lotus-FromDomain: CERTICOM
From: "Simon Blake-Wilson" <[e-mail]>
To: [e-mail]
cc: "Daniel Brown" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 8 Mar 2001 16:02:21 -0500
Subject: RE: I-D ACTION:draft-ietf-smime-ecc-03.txt
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>

Hi Francois,

Thanks. I think we only have one issue left open ... see below marked SBW>.

Best regards. Simon

a.  Sections 1, 3.2, 4.1 and 8.2, it is not clear why only the ECMQV key
agreement algorithm is supported with AuthenticatedData and not also the
ECDH key agreement algorithm.  Although ECMQV is comparable to KEA, which
can also be used with AuthenticatedData, ECDH is the analog to the X9.42
Diffie-Hellman key agreement algorithm specified in RFC 2630 and is the
default algorithm with AuthenticatedData.

--> We looked at RFC 2630 which specifies the use of ephemeral-static
Diffie-Hellman within AuthenticatedData---but we didn't understand how
this mechanism provides authentication of the sender since the sender
is not certified.  We didn't want to include the analogous technique
based on these concerns.

FR> However, as indicated in Section 4 of your ID, AuthenticatedData lacks
non-repudiation, and so in some instances is preferable to SignedData (For
example, the sending agent may not want the message to be authenticated when
forwarded).  Using ephemeral-static ECDH within AuthenticatedData can
achieve this goal, but not necessarily ECMQV or static-static ECDH, which
both require a certified public key from the sender.  As per Section 9 of
RFC 2630, the goal of AuthenticatedData is to protect the integrity of the
content, but not to necessarily provide authentication of the sender.  Note
also that RFC 2631 specifies both the ephemeral-static and the static-static
Diffie-Hellman modes.

SBW> I'm still confused. I don't think ephemeral-static DH or ECDH can
provide either data origin authentication or data integrity when used
with AuthenticatedData ... because the sender is not authenticated, an
attacker can both insert and alter messages. So I don't think
ephemeral-static DH provides any security with AuthData. Please can someone
explain to me what it provides if I'm missing something!

--> Of course we could have included static-static ECDH, but this
would involve a fixed Diffie-Hellman "shared secret" (Z) between each
pair of correspondents, which seems undesirable.

FR> True, but I though this was the reason under Section 8.2 of your ID that
the octet string ukm in the entityUInfo field of the ECC-CMS-SharedInfo
could optionally be supplied by the sending agent.  By mandating the use of
the octet string ukm with the static-static ECDH, you would certainly avoid
this undesirable effect.  Similarly, in Section 2.1.2 of RFC 2631, the
partyAInfo MUST be used in Static-Static mode, but MAY appear in
Ephemeral-Static mode to avoid this same undesirable effect.

SBW> I agree that only the shared secret Z is fixed, and varying ukm can result
in a session specific
key. However fixed Z still seems undesirable, and I don't think its sensible to
include static-static
ECDH in our draft for AuthData when it is not included in CMS for AuthData. Am I
getting anywhere
convincing you? If CMS added static-static DH for AuthData, we could certainly
add it to our draft.





[e-mail] on 03/08/2001 10:16:44 AM

To:   Daniel Brown/Certicom@Certicom
cc:   Simon Blake-Wilson/Certicom@Certicom, [e-mail]
Subject:  RE: I-D ACTION:draft-ietf-smime-ecc-03.txt




Hi Daniel,

See my responses below preceded by FR>.

Cheers,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
One Chrysalis Way
Ottawa, Ontario, CANADA, K2G 6P9
[e-mail]    Tel. [phone] ext. 3419
http://www.chrysalis-its.com   Fax. [phone]


-----Original Message-----
From: Daniel Brown [mailto:[e-mail]]
Sent: Wednesday, March 07, 2001 18:58
To: [e-mail]
Cc: Simon Blake-Wilson; [e-mail]
Subject: RE: I-D ACTION:draft-ietf-smime-ecc-03.txt


Hi Francois,

Your comments are greatly appreciated, thank you.

The responses to your comments are preceded by -->.  Comment-response
pairs are separated by line of -'s.  Most of your comments, we'll fold
into the draft.  There are a couple where we have follow-up
questions---see below.

-------------------------------------------------------------------------

a.  Sections 1, 3.2, 4.1 and 8.2, it is not clear why only the ECMQV key
agreement algorithm is supported with AuthenticatedData and not also the
ECDH key agreement algorithm.  Although ECMQV is comparable to KEA, which
can also be used with AuthenticatedData, ECDH is the analog to the X9.42
Diffie-Hellman key agreement algorithm specified in RFC 2630 and is the
default algorithm with AuthenticatedData.

--> We looked at RFC 2630 which specifies the use of ephemeral-static
Diffie-Hellman within AuthenticatedData---but we didn't understand how
this mechanism provides authentication of the sender since the sender
is not certified.  We didn't want to include the analogous technique
based on these concerns.

FR> However, as indicated in Section 4 of your ID, AuthenticatedData lacks
non-repudiation, and so in some instances is preferable to SignedData (For
example, the sending agent may not want the message to be authenticated when
forwarded).  Using ephemeral-static ECDH within AuthenticatedData can
achieve this goal, but not necessarily ECMQV or static-static ECDH, which
both require a certified public key from the sender.  As per Section 9 of
RFC 2630, the goal of AuthenticatedData is to protect the integrity of the
content, but not to necessarily provide authentication of the sender.  Note
also that RFC 2631 specifies both the ephemeral-static and the static-static
Diffie-Hellman modes.

--> Of course we could have included static-static ECDH, but this
would involve a fixed Diffie-Hellman "shared secret" (Z) between each
pair of correspondents, which seems undesirable.

FR> True, but I though this was the reason under Section 8.2 of your ID that
the octet string ukm in the entityUInfo field of the ECC-CMS-SharedInfo
could optionally be supplied by the sending agent.  By mandating the use of
the octet string ukm with the static-static ECDH, you would certainly avoid
this undesirable effect.  Similarly, in Section 2.1.2 of RFC 2631, the
partyAInfo MUST be used in Static-Static mode, but MAY appear in
Ephemeral-Static mode to avoid this same undesirable effect.

--> Make sense?  Can anyone explain how ephemeral-static
Diffie-Hellman provides security with AuthenticatedData?

FR> I do not consider myself an expert with AuthenticatedData, but see my
two responses above.

------------------------------------------------------------------------

b.  Section 1.1, although this section lists the key words used in this ID
as per RFC 2119, they are in reality used quite sparsely throughout this ID.

--> So do you want us to add more use of key words to the document?

FR> Yes since it will make checking of conformance with this ID much easier
in the future.

[snip]






Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA04901 for ietf-smime-bks; Thu, 8 Mar 2001 07:16:50 -0800 (PST)
Received: from kodiak.chrysalis-its.com ([206.47.125.131]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA04896 for <[e-mail]>; Thu, 8 Mar 2001 07:16:48 -0800 (PST)
From: [e-mail]
Received: by kodiak.chrysalis-its.com with Internet Mail Service (5.5.2650.21) id <GFG7LFSW>; Thu, 8 Mar 2001 10:16:44 -0500
Message-ID: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-ietf-smime-ecc-03.txt
Date: Thu, 8 Mar 2001 10:16:44 -0500 
X-Mailer: Internet Mail Service (5.5.2650.21)
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 Daniel,

See my responses below preceded by FR>.

Cheers, 

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
One Chrysalis Way
Ottawa, Ontario, CANADA, K2G 6P9
[e-mail]    Tel. [phone] ext. 3419
http://www.chrysalis-its.com   Fax. [phone]


-----Original Message-----
From: Daniel Brown [mailto:[e-mail]]
Sent: Wednesday, March 07, 2001 18:58
To: [e-mail]
Cc: Simon Blake-Wilson; [e-mail]
Subject: RE: I-D ACTION:draft-ietf-smime-ecc-03.txt


Hi Francois,

Your comments are greatly appreciated, thank you.

The responses to your comments are preceded by -->.  Comment-response
pairs are separated by line of -'s.  Most of your comments, we'll fold
into the draft.  There are a couple where we have follow-up
questions---see below.

-------------------------------------------------------------------------

a.  Sections 1, 3.2, 4.1 and 8.2, it is not clear why only the ECMQV key
agreement algorithm is supported with AuthenticatedData and not also the
ECDH key agreement algorithm.  Although ECMQV is comparable to KEA, which
can also be used with AuthenticatedData, ECDH is the analog to the X9.42
Diffie-Hellman key agreement algorithm specified in RFC 2630 and is the
default algorithm with AuthenticatedData.

--> We looked at RFC 2630 which specifies the use of ephemeral-static
Diffie-Hellman within AuthenticatedData---but we didn't understand how
this mechanism provides authentication of the sender since the sender
is not certified.  We didn't want to include the analogous technique
based on these concerns.

FR> However, as indicated in Section 4 of your ID, AuthenticatedData lacks
non-repudiation, and so in some instances is preferable to SignedData (For
example, the sending agent may not want the message to be authenticated when
forwarded).  Using ephemeral-static ECDH within AuthenticatedData can
achieve this goal, but not necessarily ECMQV or static-static ECDH, which
both require a certified public key from the sender.  As per Section 9 of
RFC 2630, the goal of AuthenticatedData is to protect the integrity of the
content, but not to necessarily provide authentication of the sender.  Note
also that RFC 2631 specifies both the ephemeral-static and the static-static
Diffie-Hellman modes.

--> Of course we could have included static-static ECDH, but this
would involve a fixed Diffie-Hellman "shared secret" (Z) between each
pair of correspondents, which seems undesirable.

FR> True, but I though this was the reason under Section 8.2 of your ID that
the octet string ukm in the entityUInfo field of the ECC-CMS-SharedInfo
could optionally be supplied by the sending agent.  By mandating the use of
the octet string ukm with the static-static ECDH, you would certainly avoid
this undesirable effect.  Similarly, in Section 2.1.2 of RFC 2631, the
partyAInfo MUST be used in Static-Static mode, but MAY appear in
Ephemeral-Static mode to avoid this same undesirable effect.

--> Make sense?  Can anyone explain how ephemeral-static
Diffie-Hellman provides security with AuthenticatedData?

FR> I do not consider myself an expert with AuthenticatedData, but see my
two responses above.

------------------------------------------------------------------------

b.  Section 1.1, although this section lists the key words used in this ID
as per RFC 2119, they are in reality used quite sparsely throughout this ID.

--> So do you want us to add more use of key words to the document?

FR> Yes since it will make checking of conformance with this ID much easier
in the future.

[snip]


Received: by above.proper.com (8.9.3/8.9.3) id QAA29827 for ietf-smime-bks; Wed, 7 Mar 2001 16:12:15 -0800 (PST)
Received: from mail.ca.certicom.com (ip6.certicom.com [209.121.99.6] (may be forged)) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA29822 for <[e-mail]>; Wed, 7 Mar 2001 16:12:13 -0800 (PST)
Received: from smtpmail.certicom.com (domino2.certicom.com [10.0.1.25]) by mail.ca.certicom.com (8.9.3/8.9.3) with SMTP id TAA07300; Wed, 7 Mar 2001 19:05:55 -0500 (EST)
Received: by smtpmail.certicom.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256A09.000105A9 ; Wed, 7 Mar 2001 19:11:09 -0500
X-Lotus-FromDomain: CERTICOM
From: "Simon Blake-Wilson" <[e-mail]>
To: [e-mail]
cc: [e-mail], [e-mail], [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 7 Mar 2001 19:09:57 -0500
Subject: RE: WG Last Call:draft-ietf-smime-rcek-01.txt
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>

I also have a copyright-free description of the ANSI X9.63 KDF that I can
provide if anyone is interested in adding the I-D "wrapping".

Best regards. Simon





[e-mail] on 03/07/2001 02:15:15 PM

To:   [e-mail]
cc:   [e-mail], [e-mail], [e-mail] (bcc:
      Simon Blake-Wilson/Certicom)
Subject:  RE: WG Last Call:draft-ietf-smime-rcek-01.txt




Hi William,

I also prefer the Key Derivation Function from ANSI X9.63 and I just
remembered that it is also described in Section 3.6.1 of the SECG SEC1
standard, which is freely available from the SECG web site:

http://www.secg.org/secg_docs.htm

Therefore it could be referred and used by this Internet Draft.

Cheers,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
One Chrysalis Way
Ottawa, Ontario, CANADA, K2G 6P9
[e-mail]    Tel. [phone] ext. 3419
http://www.chrysalis-its.com   Fax. [phone]

-----Original Message-----
From: William Whyte [mailto:[e-mail]]
Sent: Monday, February 19, 2001 04:58
To: Russ Housley; [e-mail]
Cc: [e-mail]
Subject: RE: WG Last Call:draft-ietf-smime-rcek-01.txt


> >William suggests byte reversal instead, which seems ok from both
perspectives.
>
> Okay.  So, since bitwise-NOT and bit-reversal both have shortcomings, what

> are you going to use as the mandatory to implement transform?

As Stephen says, I've suggested byte reversal. In fact, what I
would most like to see as the mandatory to implement transform
is X9.63 key derivation (the key derivation function referred
to as KDF2 in IEEE P1363a), but to the best of my knowledge there's
no stable, freely-available description of this that we could
reference. If anyone fancied writing it up as an RFC that'd
be very nice...

(I have to say I'm uncomfortable with the hacky use of PKCS#5
here. But at least PKCS#5 is referenceable).

Cheers,

William






Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id QAA29251 for ietf-smime-bks; Wed, 7 Mar 2001 16:01:14 -0800 (PST)
Received: from mail.ca.certicom.com (ip6.certicom.com [209.121.99.6] (may be forged)) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA29247 for <[e-mail]>; Wed, 7 Mar 2001 16:01:12 -0800 (PST)
Received: from smtpmail.certicom.com (domino2.certicom.com [10.0.1.25]) by mail.ca.certicom.com (8.9.3/8.9.3) with SMTP id SAA06982; Wed, 7 Mar 2001 18:55:00 -0500 (EST)
Received: by smtpmail.certicom.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256A09.000002E8 ; Wed, 7 Mar 2001 19:00:07 -0500
X-Lotus-FromDomain: CERTICOM
From: "Daniel Brown" <[e-mail]>
To: [e-mail]
cc: "Simon Blake-Wilson" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 7 Mar 2001 18:57:38 -0500
Subject: RE: I-D ACTION:draft-ietf-smime-ecc-03.txt
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>

Hi Francois,

Your comments are greatly appreciated, thank you.

The responses to your comments are preceded by -->.  Comment-response
pairs are separated by line of -'s.  Most of your comments, we'll fold
into the draft.  There are a couple where we have follow-up
questions---see below.

-------------------------------------------------------------------------

a.  Sections 1, 3.2, 4.1 and 8.2, it is not clear why only the ECMQV key
agreement algorithm is supported with AuthenticatedData and not also the
ECDH key agreement algorithm.  Although ECMQV is comparable to KEA, which
can also be used with AuthenticatedData, ECDH is the analog to the X9.42
Diffie-Hellman key agreement algorithm specified in RFC 2630 and is the
default algorithm with AuthenticatedData.

--> We looked at RFC 2630 which specifies the use of ephemeral-static
Diffie-Hellman within AuthenticatedData---but we didn't understand how
this mechanism provides authentication of the sender since the sender
is not certified.  We didn't want to include the analogous technique
based on these concerns.

--> Of course we could have included static-static ECDH, but this
would involve a fixed Diffie-Hellman "shared secret" (Z) between each
pair of correspondents, which seems undesirable.

--> Make sense?  Can anyone explain how ephemeral-static
Diffie-Hellman provides security with AuthenticatedData?

------------------------------------------------------------------------

b.  Section 1.1, although this section lists the key words used in this ID
as per RFC 2119, they are in reality used quite sparsely throughout this ID.

--> So do you want us to add more use of key words to the document?

-------------------------------------------------------------------------

c.  Section 2.1.1, the reference to Section 7.2 for the ECDSA-Sig-Value is
incorrect.

--> Agree.

-------------------------------------------------------------------------

d.  Sections 2.1.2 and 2.1.3, there seems to be some confusion as to whether
the message digest is a bit string, an octet string or an integer.
According to ANSI X9.30 Part 2, FIPS 180-1 and a 1999 draft revision of ANSI
X9.62, which is only available on the ANSI X9F1 web site, the message digest
is a bit string.  However, according to this ID and the SECG SEC1 standard,
the message digest is an octet string.  Finally, according to the approved
ANSI X9.62:1988 standard, the message digest magically becomes the integer
"e".  Which one is correct?

--> It seems like ANSI views octet strings as a subset of bit
strings---rather than viewing "octet strings" and "bit strings" as
separate sets, as IEEE prefers.  Fortunately, it seems like all specs
are equivalent for the cases of interest.  We'll try to clarify the ID
here.

-------------------------------------------------------------------------

e.  Sections 2.1.2 and 2.1.3, the ID should explain why it is making these
exceptions from the ANSI X9.62 standard with the integer "e".

--> Agree.

-------------------------------------------------------------------------

f.  Section 2.1.2, the last sentence should be referring to Section 8.2 when
mentioning the ECDSA-Sig-Value syntax.

--> Agree.

-------------------------------------------------------------------------

g.  Section 2.1.3, it is the integer "e'" and not "e" that is mentioned in
Section 5.4.1 of ANSI X9.62.

--> Agree.

-------------------------------------------------------------------------

h.  Section 3.1.1, the last sentence of the second paragraph should indicate
that the ECPoint represents the sending agent's ephemeral EC public key.

--> Agree.

-------------------------------------------------------------------------

i.  Section 3.1.1, the reference to Section 7.1 for the
dhSinglePass-stdDH-sha1kdf-scheme object identifier is incorrect.

--> Agree.

-------------------------------------------------------------------------

j.  Sections 3.1.3 and 3.2.3 should both indicate that the "SharedData" is
the DER encoding of ECC-CMS-SharedInfo from Section 8.2 similarly to
Sections 3.1.2 and 3.2.2.

--> Agree.

-------------------------------------------------------------------------

k.  Section 3.2.1, it is not clear why the version is mentioned in this case
and not under Section 3.1.1 since the value of 3 for the version is not
different than CMS when using the KeyAgreeRecipientInfo.

--> Agree.

-------------------------------------------------------------------------

l.  Section 3.2.1, you should be referring to Section 8.2 when mentioning
the ECPoint that represents the sending agent's ephemeral EC public key.

--> Agree.

-------------------------------------------------------------------------

m.  Section 5, why do you not refer to SEC2 instead of SEC3 when
recommending elliptic curve domain parameters?

--> Agree.

-------------------------------------------------------------------------

n.  Section 7, as per other RFCs (e.g. RFC 2876 (KEA), RFC 2984 (CAST), RFC
3058 (IDEA)), it would be very useful to include some specific DER encoding
of the SMIMECapability (e.g. ECDSA, ECDH with Triple DES wrapping).

--> Agree.

-------------------------------------------------------------------------

o.  Section 8.2, when referring to ANSI X9.63 key derivation function in the
last paragraph, the ID should also be referring to the appropriate section
of X9.63 that specifies this key derivation function (i.e. Section 5.6.3).

--> Agree.

-------------------------------------------------------------------------

p.  Section 9, although ANSI X9.62 was approved in January 1999, the
official date for referring to this standard is still 1998.

--> Agree.

-------------------------------------------------------------------------

q.  Section 9, according to the SECG web site, SEC3 is still a draft
standard and has not yet been approved.

--> Agree.

-------------------------------------------------------------------------

Thanks again,

Best regards,

Dan & Simon




Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA17285 for ietf-smime-bks; Wed, 7 Mar 2001 12:13:54 -0800 (PST)
Received: from kodiak.chrysalis-its.com ([206.47.125.131]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA17280 for <[e-mail]>; Wed, 7 Mar 2001 12:13:52 -0800 (PST)
From: [e-mail]
Received: by kodiak.chrysalis-its.com with Internet Mail Service (5.5.2650.21) id <GFG7L1DJ>; Wed, 7 Mar 2001 15:13:50 -0500
Message-ID: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-smime-ecc-03.txt
Date: Wed, 7 Mar 2001 15:13:52 -0500 
X-Mailer: Internet Mail Service (5.5.2650.21)
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 Simon,

I had a quick look over this latest Internet Draft (ID) on how to use
Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic
Message Syntax (CMS) and came up with the following technical and editorial
comments:

a.  Sections 1, 3.2, 4.1 and 8.2, it is not clear why only the ECMQV key
agreement algorithm is supported with AuthenticatedData and not also the
ECDH key agreement algorithm.  Although ECMQV is comparable to KEA, which
can also be used with AuthenticatedData, ECDH is the analog to the X9.42
Diffie-Hellman key agreement algorithm specified in RFC 2630 and is the
default algorithm with AuthenticatedData.

b.  Section 1.1, although this section lists the key words used in this ID
as per RFC 2119, they are in reality used quite sparsely throughout this ID.

c.  Section 2.1.1, the reference to Section 7.2 for the ECDSA-Sig-Value is
incorrect.

d.  Sections 2.1.2 and 2.1.3, there seems to be some confusion as to whether
the message digest is a bit string, an octet string or an integer.
According to ANSI X9.30 Part 2, FIPS 180-1 and a 1999 draft revision of ANSI
X9.62, which is only available on the ANSI X9F1 web site, the message digest
is a bit string.  However, according to this ID and the SECG SEC1 standard,
the message digest is an octet string.  Finally, according to the approved
ANSI X9.62:1988 standard, the message digest magically becomes the integer
"e".  Which one is correct?

e.  Sections 2.1.2 and 2.1.3, the ID should explain why it is making these
exceptions from the ANSI X9.62 standard with the integer "e".

f.  Section 2.1.2, the last sentence should be referring to Section 8.2 when
mentioning the ECDSA-Sig-Value syntax.

g.  Section 2.1.3, it is the integer "e'" and not "e" that is mentioned in
Section 5.4.1 of ANSI X9.62.

h.  Section 3.1.1, the last sentence of the second paragraph should indicate
that the ECPoint represents the sending agent's ephemeral EC public key.

i.  Section 3.1.1, the reference to Section 7.1 for the
dhSinglePass-stdDH-sha1kdf-scheme object identifier is incorrect.

j.  Sections 3.1.3 and 3.2.3 should both indicate that the "SharedData" is
the DER encoding of ECC-CMS-SharedInfo from Section 8.2 similarly to
Sections 3.1.2 and 3.2.2.

k.  Section 3.2.1, it is not clear why the version is mentioned in this case
and not under Section 3.1.1 since the value of 3 for the version is not
different than CMS when using the KeyAgreeRecipientInfo.

l.  Section 3.2.1, you should be referring to Section 8.2 when mentioning
the ECPoint that represents the sending agent's ephemeral EC public key.

m.  Section 5, why do you not refer to SEC2 instead of SEC3 when
recommending elliptic curve domain parameters?

n.  Section 7, as per other RFCs (e.g. RFC 2876 (KEA), RFC 2984 (CAST), RFC
3058 (IDEA)), it would be very useful to include some specific DER encoding
of the SMIMECapability (e.g. ECDSA, ECDH with Triple DES wrapping).

o.  Section 8.2, when referring to ANSI X9.63 key derivation function in the
last paragraph, the ID should also be referring to the appropriate section
of X9.63 that specifies this key derivation function (i.e. Section 5.6.3).

p.  Section 9, although ANSI X9.62 was approved in January 1999, the
official date for referring to this standard is still 1998.

q.  Section 9, according to the SECG web site, SEC3 is still a draft
standard and has not yet been approved.

Please feel free to contact me if you have any question on these comments.

Cheers,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
One Chrysalis Way
Ottawa, Ontario, CANADA, K2G 6P9
[e-mail]    Tel. [phone] ext. 3419
http://www.chrysalis-its.com   Fax. [phone]


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, March 07, 2001 07:47
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-ecc-03.txt


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 ECC Algorithms in CMS
	Author(s)	: D. Brown, S. Blake-Wilson, P. Lambert
	Filename	: draft-ietf-smime-ecc-03.txt
	Pages		: 15
	Date		: 06-Mar-01
	
This document describes how to use Elliptic Curve Cryptography
(ECC) public-key algorithms in the Cryptographic Message Syntax
(CMS).  The ECC algorithms support the creation of digital
signatures and the exchange of keys to encrypt or authenticate
content.  The definition of the algorithm processing is based on
the ANSI X9.62 standard and the ANSI X9.63 draft, developed by the
ANSI X9F1 working group.


Received: by above.proper.com (8.9.3/8.9.3) id LAA12194 for ietf-smime-bks; Wed, 7 Mar 2001 11:15:18 -0800 (PST)
Received: from kodiak.chrysalis-its.com ([206.47.125.131]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA12183 for <[e-mail]>; Wed, 7 Mar 2001 11:15:16 -0800 (PST)
From: [e-mail]
Received: by kodiak.chrysalis-its.com with Internet Mail Service (5.5.2650.21) id <GFG7LD7W>; Wed, 7 Mar 2001 14:15:14 -0500
Message-ID: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: RE: WG Last Call:draft-ietf-smime-rcek-01.txt
Date: Wed, 7 Mar 2001 14:15:15 -0500 
X-Mailer: Internet Mail Service (5.5.2650.21)
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 William,

I also prefer the Key Derivation Function from ANSI X9.63 and I just
remembered that it is also described in Section 3.6.1 of the SECG SEC1
standard, which is freely available from the SECG web site:

http://www.secg.org/secg_docs.htm

Therefore it could be referred and used by this Internet Draft.

Cheers,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
One Chrysalis Way
Ottawa, Ontario, CANADA, K2G 6P9
[e-mail]    Tel. [phone] ext. 3419
http://www.chrysalis-its.com   Fax. [phone]

-----Original Message-----
From: William Whyte [mailto:[e-mail]]
Sent: Monday, February 19, 2001 04:58
To: Russ Housley; [e-mail]
Cc: [e-mail]
Subject: RE: WG Last Call:draft-ietf-smime-rcek-01.txt


> >William suggests byte reversal instead, which seems ok from both
perspectives.
> 
> Okay.  So, since bitwise-NOT and bit-reversal both have shortcomings, what

> are you going to use as the mandatory to implement transform?

As Stephen says, I've suggested byte reversal. In fact, what I
would most like to see as the mandatory to implement transform
is X9.63 key derivation (the key derivation function referred
to as KDF2 in IEEE P1363a), but to the best of my knowledge there's
no stable, freely-available description of this that we could
reference. If anyone fancied writing it up as an RFC that'd
be very nice...

(I have to say I'm uncomfortable with the hacky use of PKCS#5
here. But at least PKCS#5 is referenceable).

Cheers,

William


Received: by above.proper.com (8.9.3/8.9.3) id EAA12850 for ietf-smime-bks; Wed, 7 Mar 2001 04:46:42 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA12845 for <[e-mail]>; Wed, 7 Mar 2001 04:46:41 -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 HAA01556; Wed, 7 Mar 2001 07:46:42 -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-ecc-03.txt
Date: Wed, 07 Mar 2001 07:46:41 -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 ECC Algorithms in CMS
	Author(s)	: D. Brown, S. Blake-Wilson, P. Lambert
	Filename	: draft-ietf-smime-ecc-03.txt
	Pages		: 15
	Date		: 06-Mar-01
	
This document describes how to use Elliptic Curve Cryptography
(ECC) public-key algorithms in the Cryptographic Message Syntax
(CMS).  The ECC algorithms support the creation of digital
signatures and the exchange of keys to encrypt or authenticate
content.  The definition of the algorithm processing is based on
the ANSI X9.62 standard and the ANSI X9.63 draft, developed by the
ANSI X9F1 working group.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-ecc-03.txt

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-ecc-03.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-ecc-03.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-ecc-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-ecc-03.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.9.3/8.9.3) id KAA07740 for ietf-smime-bks; Sun, 4 Mar 2001 10:44:45 -0800 (PST)
Received: from s-server.well-union.com.tw (s-server.well-union.com.tw [210.64.215.65]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA07724 for <[e-mail]>; Sun, 4 Mar 2001 10:44:31 -0800 (PST)
Received: from host (208.161.7.52) by s-server.well-union.com.tw (Worldmail 1.3.167); 4 Mar 2001 18:45:42 -0000
Message-ID: <[e-mail]> (added by s-server.well-union.com.tw)
From: "Victor Prestern" <[e-mail]>
Subject: The Web is Open #4FA0
To: li4fd
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3
Mime-Version: 1.0
Date: Sun, 04 Mar 2001 13:20:28 -0500
Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0"
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>

This is a MIME Message

------=_NextPart_000_007F_01BDF6C7.FABAC1B0
Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0"

------=_NextPart_001_0080_01BDF6C7.FABAC1B0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

***** This is an HTML Message ! *****


------=_NextPart_001_0080_01BDF6C7.FABAC1B0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dwindows-=
1252">
<meta name=3D"GENERATOR" content=3D"Microsoft FrontPage 4=2E0">
<meta name=3D"ProgId" content=3D"FrontPage=2EEditor=2EDocument">
<title>FREE Computer With Merchant Account Setup</title>
</head>

<body>

<center>
<p><b>COMPLETE CREDIT CARD PROCESSING SYSTEMS FOR YOUR BUSINESS=2E INTERNE=
T -  HOME
BASED -  MAIL ORDER -  PHONE ORDER</b></p>
<p><b>Do you accept credit cards? Your competition does!</b></p>
<p>&nbsp;</p>
<p>Everyone Approved - Credit Problems OK!<br>
Approval in less than 24 hours!<br>
Increase your sales by 300%<br>
Start Accepting Credit Cards on your website!<br>
Free Information, No Risk, 100% confidential=2E<br>
Your name and information will not be sold to thrid parties!<br>
Home Businesses OK!  Phone/Mail Order OK!<br>
No Application Fee, No Setup Fee!<br>
Close More Impulse Sales!<br>
<br>
</p>
<div align=3D"center">
  <table border=3D"0" cellspacing=3D"0" width=3D"85%">
    <tr>
      <td width=3D"100%">
        <p align=3D"center"><b><font face=3D"Times New Roman" size=3D"5" c=
olor=3D"#CC0000">Everyone Approved!</font></b></p>
        <p><b><font face=3D"Times New Roman"> Good Credit or Bad!&nbsp; To=
 apply today, please fill out
        the express form below=2E It
contains all the information we need to get your account approved=2E For a=
rea's
that do not apply to you please put &quot;n/a&quot; in the box=2E<br>
<br>
Upon receipt, we'll fax you with all of the all Bank Card Application
documents necessary to establish your Merchant Account=2E Once returned we=
 can
have your account approved within 24 hours=2E<br>&nbsp;</font></b>
        </p>
      </td>
    </tr>
  </table>
</div>
<table border=3D"10" cols=3D"3" width=3D"385">
  <tbody>
    <tr>
      <td align=3D"center" bgColor=3D"#990000" width=3D"119"><b><font colo=
r=3D"#ffff00" face=3D"Arial,Helvetica" size=3D"3">Service</font></b></td>
      <td align=3D"center" bgColor=3D"#990000" width=3D"160"><b><font colo=
r=3D"#ffff00" face=3D"Arial,Helvetica" size=3D"3">Industry
        Standard</font></b></td>
      <td align=3D"center" bgColor=3D"#990000" width=3D"66">
        <p align=3D"center"><b><font color=3D"#ffff00" face=3D"Arial,Helve=
tica" size=3D"3">US</font></b></p>
      </td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">Site
        Inspection</font></b></td>
      <td align=3D"middle" width=3D"160"><b><font size=3D"2">$50 - $75</fo=
nt></b></td>
      <td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica"=
 size=3D"2">FREE</font></b></td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">Shipping</font></b></td>
      <td align=3D"middle" width=3D"160"><b><font size=3D"2">$50 - $75</fo=
nt></b></td>
      <td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica"=
 size=3D"2">FREE</font></b></td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">Warranty</font></b></td>
      <td align=3D"middle" width=3D"160"><b><font size=3D"2">$10 Per Month=
</font></b></td>
      <td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica"=
 size=3D"2">FREE</font></b></td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">Sales
        Receipts</font></b></td>
      <td align=3D"middle" width=3D"160"><b><font size=3D"2">$10 - $50&nbs=
p;</font></b></td>
      <td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica"=
 size=3D"2">FREE</font></b></td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">Fraud
        Screening</font></b></td>
      </center>
    <td align=3D"middle" width=3D"160">
      <p align=3D"left"><font size=3D"2"><b>$=2E50 - $1=2E00</b><br>
      <b>Per Transaction</b></font></p>
    </td>
<center>
<td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica" size=3D=
"2">FREE</font></b></td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">Amex Set
        Up</font></b></td>
      <td align=3D"middle" width=3D"160"><b><font size=3D"2">$50 - $75</fo=
nt></b></td>
      <td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica"=
 size=3D"2">FREE</font></b></td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">24 Hour&nbsp;Help
        Line</font></b></td>
      <td align=3D"middle" width=3D"160"><b><font size=3D"2">$10 Month</fo=
nt></b></td>
      <td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica"=
 size=3D"2">FREE</font></b></td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">Security
        Bond</font></b></td>
      <td align=3D"middle" width=3D"160"><font size=3D"2"><b>$5000- $10,00=
0</b><br>
        <b>Or More</b></font></td>
      <td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica"=
 size=3D"2">NONE</font></b></td>
    </tr>
  </tbody>
</table><p>
<div align=3D"center">
  <table border=3D"0" cellspacing=3D"0" width=3D"85%">
    <tr>
      <td width=3D"100%">
        <p><font face=3D"Arial,Helvetica" size=3D"2"><b>This is a <font co=
lor=3D"#3333ff">No
        Obligation Qualification Form</font> and is your first step to<fon=
t color=3D"#cc0000">
        accepting credit cards=2E</font> By filling out this form you will=
 <font color=3D"#3333ff">&quot;not
        enter&quot;</font> in to any <font color=3D"#006600">obligations o=
r
        contracts </font>with us=2E We will use it to determine the best p=
rogram
        to offer you based on the information you provide=2E You will be c=
ontacted by one of our representatives within 1-2 business days to go over =
the rest of your account set up=2E</b></font>
        <p align=3D"center"><font face=3D"Arial,Helvetica" size=3D"2"><b><=
font color=3D"#cc0000">Note:</font>&nbsp;
        All Information Provided To Us <font color=3D"#cc0000">Will Remain=
 100%
        Confidential</font>
        !!&nbsp;</b></font></td>
    </tr>
  </table>
</div>
<table border=3D"0">
  <tbody>
    <tr>
      <td width=3D"100%">
        <p align=3D"center"><b><font color=3D"#000099" face=3D"arial" size=
=3D"+2">Apply
        Free With No Risk!</font></b></p>
      </td>
    </tr>
  </tbody>
</table>
  </center>
</form>
<div align=3D"left">
  <table border=3D"0" width=3D"95%">
    <tr>
      <td width=3D"100%">
        <p align=3D"center"><b><i><font size=3D"2" color=3D"#CC0000">Pleas=
e fill out the
        express application form completely=2E<br>Incomplete information m=
ay prevent us from properly
        processing your application=2E</font></i></b></p>
      </td>
    </tr>
  </table>
</div>
<form name=3D"form"
  method=3D"post"
  action=3D"mailto:ytzz@cmpmail=2Ecom?SUBJECT=3DMerchant Form"
  enctype=3D"text/plain"
  
 
 <tr>
<div align=3D"left">
  <table border=3D"0" width=3D"95%">
    <tr>
      <td width=3D"61%" align=3D"right"><font size=3D"2"><b>Your Full Emai=
l Address:</b><br>
        <font color=3D"#ff0000">be sure to use your full address </font>(i=
=2Ee=2E<font color=3D"#ff0000">
        </font>user@domain=2Ecom)</font></td>
      <td width=3D"39%" align=3D"center"><input type=3D"text" name=3D"user=
_email" size=3D"29"></td>
    </tr>
    <tr>
      <td width=3D"61%" align=3D"right"><b><font size=3D"2">Your Name:</fo=
nt></b></td>
      <td width=3D"39%" align=3D"center"><input type=3D"text" name=3D"Appl=
icant_Name" size=3D"29"></td>
    </tr>
    <tr>
      <td width=3D"61%" align=3D"right"><b><font size=3D"2">Business Name:=
</font></b></td>
      <td width=3D"39%" align=3D"center"><input type=3D"text" name=3D"Busi=
ness_Name" size=3D"29"></td>
    </tr>
    <tr>
      <td width=3D"61%" align=3D"right"><b><font size=3D"2">Business Phone=
 Number:</font></b></td>
      <td width=3D"39%" align=3D"center"><input type=3D"text" name=3D"Busi=
ness_Phone" size=3D"29"></td>
    </tr>
    <tr>
      <td width=3D"61%" align=3D"right"><b><font size=3D"2">Home Phone Num=
ber:</font></b></td>
      <td width=3D"39%" align=3D"center"><input type=3D"text" name=3D"Home=
Phone" size=3D"29"></td>
    </tr>
    <tr>
      <td width=3D"61%" align=3D"right"><b><font size=3D"2">Type of Busine=
ss:</font></b></td>
      <td width=3D"39%">
        <div align=3D"left">
          <table border=3D"0" width=3D"95%">
            <tr>
              <td width=3D"12%" align=3D"center"><input type=3D"radio" val=
ue=3D"retail" name=3D"Type_Business"></td>
              <td width=3D"88%"><font size=3D"2"><b>Retail Business</b></f=
ont></td>
            </tr>
            <tr>
              <td width=3D"12%" align=3D"center"><input type=3D"radio" val=
ue=3D"mailorder" name=3D"Type_Business"></td>
              <td width=3D"88%"><font size=3D"2"><b>Mail Order Business</b=
></font></td>
            </tr>
            <tr>
              <td width=3D"12%" align=3D"center"><input type=3D"radio" val=
ue=3D"internet" name=3D"Type_Business"></td>
              <td width=3D"88%"><font size=3D"2"><b>Internet Based Busines=
s</b></font></td>
            </tr>
          </table>
        </div>
      </td>
    </tr>
    <tr>
      <td width=3D"61%" align=3D"right"><b><font size=3D"2">Personal Credi=
t Rating:</font></b></td>
      <td width=3D"39%">
        <div align=3D"left">
          <table border=3D"0" width=3D"95%">
            <tr>
              <td width=3D"12%" align=3D"center"><input type=3D"radio" val=
ue=3D"excellent" name=3D"Credit_Rank"></td>
              <td width=3D"88%">Excellent</td>
            </tr>
            <tr>
              <td width=3D"12%" align=3D"center"><input type=3D"radio" val=
ue=3D"good" name=3D"Credit_Rank"></td>
              <td width=3D"88%">Good</td>
            </tr>
            <tr>
              <td width=3D"12%" align=3D"center"><input type=3D"radio" val=
ue=3D"fair" name=3D"Credit_Rank"></td>
              <td width=3D"88%">Fair</td>
            </tr>
            <tr>
              <td width=3D"12%" align=3D"center"><input type=3D"radio" val=
ue=3D"poor" name=3D"Credit_Rank"></td>
              <td width=3D"88%">Poor</td>
            </tr>
          </table>
        </div>
      </td>
    </tr>
    <tr>
      <td width=3D"61%" align=3D"right"><b><font size=3D"2">How Soon Would=
 You Like a Merchant
        Account?</font></b></td>
      <td width=3D"39%">
        <p align=3D"center"><input type=3D"text" name=3D"How_Soon" size=3D=
"29"></p>
      </td>
    </tr>
    <tr>
      <td width=3D"100%" colspan=3D"2">
        <div align=3D"center">
          <center>
          <table border=3D"0" width=3D"13%">
            <tr>
              <td width=3D"100%">
                <p align=3D"center"><input type=3D"submit" value=3D"Submit=
" name=3D"B1"></td>
            </tr>
          </table>
          </center>
        </div>
      </td></form>
    </tr>
  </table>
</div><br>
<div align=3D"center">
  <center>
  <table border=3D"3" cellspacing=3D"0" width=3D"85%" bgcolor=3D"#E8E8E8" =
bordercolor=3D"#C0C0C0">
    <tr>
      <td width=3D"100%" bgcolor=3D"#E8E8E8"><font size=3D"2"><b>Your info=
rmation is confidential, it will not be sold or used for any other purpose,=
 and you are under no obligation=2E
        Your information will be used solely for the purpose of evaluating=
 your business or website for a merchant account so that you may begin acce=
pting credit card payments=2E</b></font>
      </td>
    </tr>
  </table>
  </center>
</div>

</form>

<p align=3D"center">
<br><b><font size=3D"3" color=3D"#FF0000">List
 Removal/OPT-OUT Option</font></b>
 <br><b><font color=3D"#000000"><font size=3D-1><a
 href=3D"mailto:pgdkk@netscape=2Enet?subject=3Dremove">Click
 Here</a></font></font></b>

</body>


</html>


------=_NextPart_001_0080_01BDF6C7.FABAC1B0--

------=_NextPart_000_007F_01BDF6C7.FABAC1B0--





Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA10362 for ietf-smime-bks; Thu, 1 Mar 2001 09:50:57 -0800 (PST)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by above.proper.com (8.9.3/8.9.3) with SMTP id JAA10358 for <[e-mail]>; Thu, 1 Mar 2001 09:50:56 -0800 (PST)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.7)); Thu, 01 Mar 2001 09:50:27 -0800
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by cane.deming.com with Internet Mail Service (5.5.2650.21) id <CXGVMTKW>; Thu, 1 Mar 2001 09:50:27 -0800
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'William Ottaway'" <[e-mail]>, "'Russ Housley'" <[e-mail]>
cc: "Bonatti, Chris" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Certs-only Mechanism for X.400 Transport
Date: Thu, 1 Mar 2001 09:50:25 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 1680546952450-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>

Sounds good -- we'll rewrite it at some point.

Blake

-----Original Message-----
From: William Ottaway [mailto:[e-mail]]
Sent: Thursday, March 01, 2001 1:11 AM
To: Blake Ramsdell; 'Russ Housley'
Cc: Bonatti, Chris; [e-mail]; [e-mail]
Subject: RE: Certs-only Mechanism for X.400 Transport


Blake,

I have no problem with pushing CRLs through a CMS message. I have a problem
with the text "certificates-only Message" because it is misleading. I
believe the text in 3.6 should refer to a certificate management message.

3.6 Creating a Certificate Management Message

   The certificate management message or MIME entity is used to transport
   certificates and/or CRLs, such as in response to a registration request.

   Step 1. The certificates and/or CRLs are made available to the CMS
generating
   process which creates a CMS object of type signedData. The signedData
   encapContentInfo eContent field MUST be absent and signerInfos field
   MUST be empty.

   Step 2. The CMS signedData object is enclosed in an
   application/pkcs7-mime MIME entity

   The smime-type parameter for a certificate management message is
"cert-management".
   The file extension for this type of message is ".p7c".


Bill.


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Blake Ramsdell
> Sent: 28 February 2001 20:36
> To: 'Russ Housley'; William Ottaway
> Cc: Bonatti, Chris; [e-mail]; [e-mail]
> Subject: RE: Certs-only Mechanism for X.400 Transport
>
>
> Section 3.6 currently reads (sorry if it wraps)
>
> > 3.6 Creating a Certificates-only Message
> >
> >    The certificates only message or MIME entity is used to transport
> >    certificates, such as in response to a registration request. This
> >    format can also be used to convey CRLs.
> >
> >    Step 1. The certificates are made available to the CMS generating
> >    process which creates a CMS object of type signedData. The signedData
> >    encapContentInfo eContent field MUST be absent and signerInfos field
> >    MUST be empty.
> >
> >    Step 2. The CMS signedData object is enclosed in an
> >    application/pkcs7-mime MIME entity
> >
> >    The smime-type parameter for a certs-only message is "certs-only".
> >    The file extension for this type of message is ".p7c".
>
> These steps are valid for sending CRLs also, if that is ambiguous.  Step 1
> can be modified to read "The certificates and/or CRLs".  Pushing CRLs
> through a CMS message is a valid idea (at least I think so), and
> in fact we
> do it for our own product (we chase down CRLs and package thm in CMS
> messages).
>
> Blake
>
> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Wednesday, February 28, 2001 5:57 AM
> To: William Ottaway
> Cc: Bonatti, Chris; [e-mail]; [e-mail]
> Subject: RE: Certs-only Mechanism for X.400 Transport
>
>
> I was not part of the S/MIME v2 discussions that lead to the current
> format.  I have asked Blake to chime in, and I hope that he does.  The
> scenario of interest is a CA returning a certificate in response to the
> PKCS#10 request.  Here, the CA could choose to include the
> current CRLs in
> the "cert-only" message.  This would seed the newly-enrolled user's CRL
> cache.
>
> I am not aware of any CA pushing CRLs to their subscribers in an S/MIME
> message.  It could certainly be done....
>
> Russ
>
> At 04:30 PM 2/26/2001 +0000, William Ottaway wrote:
> >Chris,
> >
> >I'm happy for the text to indicate that the format described for a certs
> >only message could be used to transport CRLs or both, as long as the text
> >also states that if CRLs or both are being transported the OID for certs
> >only MUST not be used.
> >
> >Do we have consensus :-)
> >
> >Bill.
> >
> > > -----Original Message-----
> > > From: Bonatti, Chris [mailto:[e-mail]]
> > > Sent: 26 February 2001 16:10
> > > To: William Ottaway
> > > Cc: [e-mail]; [e-mail]
> > > Subject: Re: Certs-only Mechanism for X.400 Transport
> > >
> > >
> > > Bill,
> > >
> > >     Okay, how about option (3)  ;-)
> > >
> > >     (3) would be we clarify the text, but describe more clearly
> > > what I think was
> > > the intent of RFC 2633.  Namely, that the format described and
> > > identified as
> > > "certs-only" can be used to convey either certs, CRLs or both.
> > >
> > >     Btw, I would happily go along with either (1) or (2) if the
> > > corresponding
> > > change were made to the MSG spec.  I guess I still favor (3)
> > > however, because I
> > > perceive it to be the status quo, and because allowing CRLs to be
> > > included here
> > > doesn't seem to break anything for the PKCS #10 scenario.  I'd be
> > > hard pressed
> > > to cite the benefits, though.  Does anybody remember the logic
> > > for why this was
> > > done?
> > >
> > > Chris
> > >
> > >
> > > _______________________
> > >
> > > William Ottaway wrote:
> > >
> > > > Jim,
> > > >
> > > > I think I'm inferring what is done. :-)
> > > >
> > > > My only gripe is I don't like the statement "This format can
> > > also be used to
> > > > convey CRLs." followed by a description of how to carry
> > > certificates but no
> > > > description of how to carry CRLs in a similar format.
> > > >
> > > > Its too late to change RFC 2633 but draft-ietf-smime-x400trans could
> say
> > > > something different.
> > > >
> > > > 1) Don't mention that CRLs can be carried in a similar way to a
> > > certs only
> > > > message
> > > >
> > > > or
> > > >
> > > > 2) Specify an OID for a CRL only message.
> > > >
> > > > Bill.
> > > >
> > >
>
>





Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id EAA11588 for ietf-smime-bks; Thu, 1 Mar 2001 04:22:06 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA11582 for <[e-mail]>; Thu, 1 Mar 2001 04:22:04 -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 HAA01124; Thu, 1 Mar 2001 07:22:04 -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-06.txt
Date: Thu, 01 Mar 2001 07:22:04 -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-06.txt
	Pages		: 8
	Date		: 28-Feb-01
	
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-06.txt

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-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-examples-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-examples-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-examples-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 majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id BAA19193 for ietf-smime-bks; Thu, 1 Mar 2001 01:05:41 -0800 (PST)
Received: from mail.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by above.proper.com (8.9.3/8.9.3) with SMTP id BAA19180 for <[e-mail]>; Thu, 1 Mar 2001 01:05:38 -0800 (PST)
Received: (qmail 14450 invoked from network); 1 Mar 2001 09:05:35 -0000
Received: from cray.eris.dera.gov.uk (HELO mailhost.eris.dera.gov.uk) (128.98.2.7) by ens0.eris.dera.gov.uk with SMTP; 1 Mar 2001 09:05:35 -0000
Received: (qmail 6496 invoked from network); 1 Mar 2001 09:05:34 -0000
Received: from wottaway.eris.dera.gov.uk (HELO wottaway) (128.98.10.192) by mailhost.eris.dera.gov.uk with SMTP; 1 Mar 2001 09:05:33 -0000
From: "William Ottaway" <[e-mail]>
To: "Blake Ramsdell" <[e-mail]>, "'Russ Housley'" <[e-mail]>
Cc: "Bonatti, Chris" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Certs-only Mechanism for X.400 Transport
Date: Thu, 1 Mar 2001 09:10:33 -0000
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)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
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 have no problem with pushing CRLs through a CMS message. I have a problem
with the text "certificates-only Message" because it is misleading. I
believe the text in 3.6 should refer to a certificate management message.

3.6 Creating a Certificate Management Message

   The certificate management message or MIME entity is used to transport
   certificates and/or CRLs, such as in response to a registration request.

   Step 1. The certificates and/or CRLs are made available to the CMS
generating
   process which creates a CMS object of type signedData. The signedData
   encapContentInfo eContent field MUST be absent and signerInfos field
   MUST be empty.

   Step 2. The CMS signedData object is enclosed in an
   application/pkcs7-mime MIME entity

   The smime-type parameter for a certificate management message is
"cert-management".
   The file extension for this type of message is ".p7c".


Bill.


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Blake Ramsdell
> Sent: 28 February 2001 20:36
> To: 'Russ Housley'; William Ottaway
> Cc: Bonatti, Chris; [e-mail]; [e-mail]
> Subject: RE: Certs-only Mechanism for X.400 Transport
>
>
> Section 3.6 currently reads (sorry if it wraps)
>
> > 3.6 Creating a Certificates-only Message
> >
> >    The certificates only message or MIME entity is used to transport
> >    certificates, such as in response to a registration request. This
> >    format can also be used to convey CRLs.
> >
> >    Step 1. The certificates are made available to the CMS generating
> >    process which creates a CMS object of type signedData. The signedData
> >    encapContentInfo eContent field MUST be absent and signerInfos field
> >    MUST be empty.
> >
> >    Step 2. The CMS signedData object is enclosed in an
> >    application/pkcs7-mime MIME entity
> >
> >    The smime-type parameter for a certs-only message is "certs-only".
> >    The file extension for this type of message is ".p7c".
>
> These steps are valid for sending CRLs also, if that is ambiguous.  Step 1
> can be modified to read "The certificates and/or CRLs".  Pushing CRLs
> through a CMS message is a valid idea (at least I think so), and
> in fact we
> do it for our own product (we chase down CRLs and package thm in CMS
> messages).
>
> Blake
>
> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Wednesday, February 28, 2001 5:57 AM
> To: William Ottaway
> Cc: Bonatti, Chris; [e-mail]; [e-mail]
> Subject: RE: Certs-only Mechanism for X.400 Transport
>
>
> I was not part of the S/MIME v2 discussions that lead to the current
> format.  I have asked Blake to chime in, and I hope that he does.  The
> scenario of interest is a CA returning a certificate in response to the
> PKCS#10 request.  Here, the CA could choose to include the
> current CRLs in
> the "cert-only" message.  This would seed the newly-enrolled user's CRL
> cache.
>
> I am not aware of any CA pushing CRLs to their subscribers in an S/MIME
> message.  It could certainly be done....
>
> Russ
>
> At 04:30 PM 2/26/2001 +0000, William Ottaway wrote:
> >Chris,
> >
> >I'm happy for the text to indicate that the format described for a certs
> >only message could be used to transport CRLs or both, as long as the text
> >also states that if CRLs or both are being transported the OID for certs
> >only MUST not be used.
> >
> >Do we have consensus :-)
> >
> >Bill.
> >
> > > -----Original Message-----
> > > From: Bonatti, Chris [mailto:[e-mail]]
> > > Sent: 26 February 2001 16:10
> > > To: William Ottaway
> > > Cc: [e-mail]; [e-mail]
> > > Subject: Re: Certs-only Mechanism for X.400 Transport
> > >
> > >
> > > Bill,
> > >
> > >     Okay, how about option (3)  ;-)
> > >
> > >     (3) would be we clarify the text, but describe more clearly
> > > what I think was
> > > the intent of RFC 2633.  Namely, that the format described and
> > > identified as
> > > "certs-only" can be used to convey either certs, CRLs or both.
> > >
> > >     Btw, I would happily go along with either (1) or (2) if the
> > > corresponding
> > > change were made to the MSG spec.  I guess I still favor (3)
> > > however, because I
> > > perceive it to be the status quo, and because allowing CRLs to be
> > > included here
> > > doesn't seem to break anything for the PKCS #10 scenario.  I'd be
> > > hard pressed
> > > to cite the benefits, though.  Does anybody remember the logic
> > > for why this was
> > > done?
> > >
> > > Chris
> > >
> > >
> > > _______________________
> > >
> > > William Ottaway wrote:
> > >
> > > > Jim,
> > > >
> > > > I think I'm inferring what is done. :-)
> > > >
> > > > My only gripe is I don't like the statement "This format can
> > > also be used to
> > > > convey CRLs." followed by a description of how to carry
> > > certificates but no
> > > > description of how to carry CRLs in a similar format.
> > > >
> > > > Its too late to change RFC 2633 but draft-ietf-smime-x400trans could
> say
> > > > something different.
> > > >
> > > > 1) Don't mention that CRLs can be carried in a similar way to a
> > > certs only
> > > > message
> > > >
> > > > or
> > > >
> > > > 2) Specify an OID for a CRL only message.
> > > >
> > > > Bill.
> > > >
> > >
>
>