Subject: Re: UNSUBSCRIBE

From: Natalia Syracuse <[email-masked]>
Date: Fri, 30 Mar 2001 10:27:31 -0500 (Eastern Standard Time)

Attention please!!!

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

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

Natalia Syracuse

On Fri, 30 Mar 2001, John Greco wrote:

> UNSUBSCRIBE

Date: Fri, 30 Mar 2001 10:27:31 -0500 (Eastern Standard Time)
From: Natalia Syracuse <[email-masked]>
To: John Greco <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: UNSUBSCRIBE
Sender: [email-masked]

Attention please!!!

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

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

Natalia Syracuse

On Fri, 30 Mar 2001, John Greco wrote:

> UNSUBSCRIBE

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-pkcs1-00.txt
Date: Fri, 30 Mar 2001 07:31:00 -0500
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Thu, 29 Mar 2001 15:05:35 -0500
From: "Bonatti, Chris" <[email-masked]>
Organization: IECA, Inc.
To: IETF S/MIME WG <[email-masked]>
Subject: Revised section 2.5 of draft-ietf-smime-x400transport-01
Sender: [email-masked]

    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) }

From: [email-masked]
To: [email-masked]
Date: Wed, 28 Mar 01 02:33:16 EST
Subject: toner supplies
Reply-To: [email-masked]
Sender: [email-masked]

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:1-888-288-9043
ORDER BY FAX: 1-888-977-1577
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.

Date: Tue, 27 Mar 2001 11:25:00 -0500
To: [email-masked], [email-masked]
From: Russ Housley <[email-masked]>
Subject: Need an OID from the S/MIME arc?
Sender: [email-masked]

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 <[email-masked]>.  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 

From: [email-masked]
To: [email-masked]
Date: Tue, 27 Mar 2001 14:27:02 -0500
Subject: virus warning - HAHAHA
Sender: [email-masked]

   The message obstensibly from [email-masked] 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.

Date: Tue, 27 Mar 2001 05:31:51 -0800 (PST)
From: Hahaha <[email-masked]>
Subject: Enanito si, pero con que pedazo!
Sender: [email-masked]

----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"

AAAAAAAAAAAAAAAA

----VEKTA7C5E70P--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-aes-alg-01.txt
Date: Mon, 26 Mar 2001 18:37:57 -0500
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Mon, 26 Mar 2001 14:18:57 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: pkix <[email-masked]>, S-MIME / IETF <[email-masked]>
Subject: ETSI ESI call on Policy requirements for TSAs
Sender: [email-masked]

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:[email-masked]

Regards,

Denis

From: "[email-masked]" <[email-masked]>
To: [email-masked]
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?
Sender: [email-masked]

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

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

From: "Rexford Harris" <[email-masked]>
Subject: All VIP's
To: <#field0#>
Date: Sat, 24 Mar 2001 10:05:36 -0700
Sender: [email-masked]

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--

From: "Pawling, John" <[email-masked]>
To: SMIME <[email-masked]>, "Stephen Farrell (E-mail)" <[email-masked]>
Subject: RE: certificate and attribute certificate imported from PKIX or X .509
Date: Fri, 23 Mar 2001 09:36:28 -0500
Sender: [email-masked]

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, [email-masked]
Getronics Government Solutions, LLC
===========================================

-----Original Message-----
From: Sean P. Turner [mailto:[email-masked]]
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, [email-masked]
> Getronics Government Solutions, LLC
> ===========================================
>
> -----Original Message-----
> From: Dr S N Henson [mailto:[email-masked]]
> 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: [email-masked]
> Senior crypto engineer, Celo Communications: http://www.celocom.com/
> Core developer of the   OpenSSL project: http://www.openssl.org/
> Business Email: [email-masked] PGP key: via homepage.

Date: Fri, 23 Mar 2001 03:11:12 -0500
From: "Sean P. Turner" <[email-masked]>
To: SMIME <[email-masked]>
CC: "Pawling, John" <[email-masked]>, "Stephen Farrell (E-mail)" <[email-masked]>
Subject: Re: certificate and attribute certificate imported from PKIX or X.509
Sender: [email-masked]

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, [email-masked]
> Getronics Government Solutions, LLC
> ===========================================
>
> -----Original Message-----
> From: Dr S N Henson [mailto:[email-masked]]
> 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: [email-masked]
> Senior crypto engineer, Celo Communications: http://www.celocom.com/
> Core developer of the   OpenSSL project: http://www.openssl.org/
> Business Email: [email-masked] PGP key: via homepage.

From: "Pawling, John" <[email-masked]>
To: SMIME <[email-masked]>, "Stephen Farrell (E-mail)" <[email-masked]>
Subject: RE: certificate and attribute certificate imported from PKIX or X .509
Date: Thu, 22 Mar 2001 17:37:44 -0500
Sender: [email-masked]

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, [email-masked]
Getronics Government Solutions, LLC
===========================================

-----Original Message-----
From: Dr S N Henson [mailto:[email-masked]]
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: [email-masked] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [email-masked] PGP key: via homepage.

Date: Thu, 22 Mar 2001 21:33:00 +0000
From: Dr S N Henson <[email-masked]>
Organization: S N Henson
To: SMIME <[email-masked]>
Subject: Re: certificate and attribute certificate imported from PKIX or X.509
Sender: [email-masked]

"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: [email-masked] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [email-masked] PGP key: via homepage.

From: "Blake Ramsdell" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, [email-masked]
Subject: RE: Mandatory to Implement Algorithms
Date: Thu, 22 Mar 2001 12:56:11 -0800
Sender: [email-masked]

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:[email-masked]]
Sent: Thursday, March 22, 2001 12:00 PM
To: [email-masked]
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

Date: Thu, 22 Mar 2001 14:59:56 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Mandatory to Implement Algorithms
Sender: [email-masked]

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

Date: Thu, 22 Mar 2001 14:12:40 -0500
From: "Sean P. Turner" <[email-masked]>
To: SMIME <[email-masked]>
Subject: Re: certificate and attribute certificate imported from PKIX or X.509
Sender: [email-masked]

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, [email-masked]
> Getronics Government Solutions, LLC
> ===========================================
>
>
> -----Original Message-----
> From: Sean P. Turner [mailto:[email-masked]]
> 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

From: "Pawling, John" <[email-masked]>
To: SMIME <[email-masked]>
Subject: RE: certificate and attribute certificate imported from PKIX or X .509
Date: Thu, 22 Mar 2001 13:41:39 -0500
Sender: [email-masked]

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, [email-masked]
Getronics Government Solutions, LLC
===========================================

-----Original Message-----
From: Sean P. Turner [mailto:[email-masked]]
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

Date: Thu, 22 Mar 2001 11:30:06 -0500
From: "Sean P. Turner" <[email-masked]>
To: SMIME <[email-masked]>
Subject: certificate and attribute certificate imported from PKIX or X.509
Sender: [email-masked]

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

Date: Wed, 21 Mar 2001 14:25:24 -0500
From: "Sean P. Turner" <[email-masked]>
To: SMIME <[email-masked]>
Subject: comments on draft-ietf-smime-symkeydist-02.txt
Sender: [email-masked]

--------------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--

From: "Eggen, Anders" <[email-masked]>
To: "'Prasad, Nandi'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: SV: S/MIME support in SMTP Gateway
Date: Wed, 21 Mar 2001 14:20:41 +0100
Sender: [email-masked]

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:[email-masked]]
> Sendt:	Wednesday, March 21, 2001 12:35 PM
> Til:	[email-masked]'
> 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:[email-masked]]</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">[email-masked]'</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--

From: "Prasad, Nandi" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: S/MIME support in SMTP Gateway
Date: Wed, 21 Mar 2001 17:04:55 +0530
Sender: [email-masked]

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

From: [email-masked]
To: [email-masked]
Date: Tue, 20 Mar 2001 16:08:21 +0100
Subject: About Mime Format
Sender: [email-masked]

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.

From: [email-masked]
To: 
Subject: DAMAGED GEAR
Date: Sun, 18 Mar 01 23:57:58 Eastern Standard Time
Reply-To: [email-masked]
Importance: High
Sender: [email-masked]

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 [email-masked]&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>

To: [email-masked]
Subject: Million Message Attack draft
Date: Sat, 17 Mar 2001 21:07:52 -0800
From: Eric Rescorla <[email-masked]>
Sender: [email-masked]

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 <[email-masked]>
RTFM, Inc.
2439 Alvin Drive
Mountain View, CA 94043
Phone: (650) 314-0116

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

From: "Neil P. Meyer" <[email-masked]>
Subject: Compared #563A
To: [email-masked]
Date: Sat, 17 Mar 2001 13:32:23 -0500
Sender: [email-masked]

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--

Date: Fri, 9 Mar 2001 16:51:01 +0100 (W. Europe Standard Time)
From: Magnus Nystrom <[email-masked]>
Reply-To: <[email-masked]>
To: <[email-masked]>
Subject: RE: WG Last Call:draft-ietf-smime-rcek-01.txt 
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-symkeydist-03.txt
Date: Fri, 09 Mar 2001 07:37:21 -0500
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Simon Blake-Wilson" <[email-masked]>
To: [email-masked]
cc: "Daniel Brown" <[email-masked]>, [email-masked]
Date: Thu, 8 Mar 2001 16:02:21 -0500
Subject: RE: I-D ACTION:draft-ietf-smime-ecc-03.txt
Sender: [email-masked]

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.

[email-masked] on 03/08/2001 10:16:44 AM

To:   Daniel Brown/Certicom@Certicom
cc:   Simon Blake-Wilson/Certicom@Certicom, [email-masked]
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
[email-masked]    Tel. (613) 723-5076 ext. 3419
http://www.chrysalis-its.com   Fax. (613) 723-5078

-----Original Message-----
From: Daniel Brown [mailto:[email-masked]]
Sent: Wednesday, March 07, 2001 18:58
To: [email-masked]
Cc: Simon Blake-Wilson; [email-masked]
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]

From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-ietf-smime-ecc-03.txt
Date: Thu, 8 Mar 2001 10:16:44 -0500 
Sender: [email-masked]

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
[email-masked]    Tel. (613) 723-5076 ext. 3419
http://www.chrysalis-its.com   Fax. (613) 723-5078

-----Original Message-----
From: Daniel Brown [mailto:[email-masked]]
Sent: Wednesday, March 07, 2001 18:58
To: [email-masked]
Cc: Simon Blake-Wilson; [email-masked]
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]

From: "Simon Blake-Wilson" <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Wed, 7 Mar 2001 19:09:57 -0500
Subject: RE: WG Last Call:draft-ietf-smime-rcek-01.txt
Sender: [email-masked]

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

[email-masked] on 03/07/2001 02:15:15 PM

To:   [email-masked]
cc:   [email-masked], [email-masked], [email-masked] (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
[email-masked]    Tel. (613) 723-5076 ext. 3419
http://www.chrysalis-its.com   Fax. (613) 723-5078

-----Original Message-----
From: William Whyte [mailto:[email-masked]]
Sent: Monday, February 19, 2001 04:58
To: Russ Housley; [email-masked]
Cc: [email-masked]
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

From: "Daniel Brown" <[email-masked]>
To: [email-masked]
cc: "Simon Blake-Wilson" <[email-masked]>, [email-masked]
Date: Wed, 7 Mar 2001 18:57:38 -0500
Subject: RE: I-D ACTION:draft-ietf-smime-ecc-03.txt
Sender: [email-masked]

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

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-smime-ecc-03.txt
Date: Wed, 7 Mar 2001 15:13:52 -0500 
Sender: [email-masked]

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
[email-masked]    Tel. (613) 723-5076 ext. 3419
http://www.chrysalis-its.com   Fax. (613) 723-5078

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 07, 2001 07:47
Cc: [email-masked]
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.

From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: WG Last Call:draft-ietf-smime-rcek-01.txt
Date: Wed, 7 Mar 2001 14:15:15 -0500 
Sender: [email-masked]

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
[email-masked]    Tel. (613) 723-5076 ext. 3419
http://www.chrysalis-its.com   Fax. (613) 723-5078

-----Original Message-----
From: William Whyte [mailto:[email-masked]]
Sent: Monday, February 19, 2001 04:58
To: Russ Housley; [email-masked]
Cc: [email-masked]
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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-ecc-03.txt
Date: Wed, 07 Mar 2001 07:46:41 -0500
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Victor Prestern" <[email-masked]>
Subject: The Web is Open #4FA0
To: li4fd
Date: Sun, 04 Mar 2001 13:20:28 -0500
Sender: [email-masked]

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--

From: "Blake Ramsdell" <[email-masked]>
To: "'William Ottaway'" <[email-masked]>, "'Russ Housley'" <[email-masked]>
cc: "Bonatti, Chris" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Certs-only Mechanism for X.400 Transport
Date: Thu, 1 Mar 2001 09:50:25 -0800
Sender: [email-masked]

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

Blake

-----Original Message-----
From: William Ottaway [mailto:[email-masked]]
Sent: Thursday, March 01, 2001 1:11 AM
To: Blake Ramsdell; 'Russ Housley'
Cc: Bonatti, Chris; [email-masked]; [email-masked]
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: [email-masked]
> [mailto:[email-masked]]On Behalf Of Blake Ramsdell
> Sent: 28 February 2001 20:36
> To: 'Russ Housley'; William Ottaway
> Cc: Bonatti, Chris; [email-masked]; [email-masked]
> 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:[email-masked]]
> Sent: Wednesday, February 28, 2001 5:57 AM
> To: William Ottaway
> Cc: Bonatti, Chris; [email-masked]; [email-masked]
> 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:[email-masked]]
> > > Sent: 26 February 2001 16:10
> > > To: William Ottaway
> > > Cc: [email-masked]; [email-masked]
> > > 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.
> > > >
> > >
>
>

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-examples-06.txt
Date: Thu, 01 Mar 2001 07:22:04 -0500
Sender: [email-masked]

--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 <[email-masked]> 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 <[email-masked]> 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "William Ottaway" <[email-masked]>
To: "Blake Ramsdell" <[email-masked]>, "'Russ Housley'" <[email-masked]>
Cc: "Bonatti, Chris" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Certs-only Mechanism for X.400 Transport
Date: Thu, 1 Mar 2001 09:10:33 -0000
Importance: Normal
Sender: [email-masked]

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: [email-masked]
> [mailto:[email-masked]]On Behalf Of Blake Ramsdell
> Sent: 28 February 2001 20:36
> To: 'Russ Housley'; William Ottaway
> Cc: Bonatti, Chris; [email-masked]; [email-masked]
> 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:[email-masked]]
> Sent: Wednesday, February 28, 2001 5:57 AM
> To: William Ottaway
> Cc: Bonatti, Chris; [email-masked]; [email-masked]
> 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:[email-masked]]
> > > Sent: 26 February 2001 16:10
> > > To: William Ottaway
> > > Cc: [email-masked]; [email-masked]
> > > 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.
> > > >
> > >
>
>