RE: A general question about S/MIMEv2 & v3

["Ozan Gonenc" <[e-mail]>]

Hello Laurent,

New functionalities include:
- Increased interoperability and support for digital signatures (V3 clients
support both DSA and RSA)
- V3 supports both D-H and RSA
- V3 supports secondary crypto algorithms
- D-H support is mandatory
- ESS (signed receipts, security labels, Secure MLAs, Signed certificates)
- V3 agent may generate separate D-H and DSS public/private key pairs on
behalf of the user

A number of software vendors are beginning to migrate to S/MIME v3 in phases
as the demand for extended security services increases.  Currently no
software vendors have incorporated "full" v3 compliance.

Hope this helps!

Cheers,

______________________________

Ozan Gonenc, B.Sc.
IT Security Consultant

AEPOS Technologies Corporation
[phone] x. 230 (Office)
[phone] (Fax)



-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Laurent Deffranne
Sent: October 30, 2000 09:28
To: ietf-smime
Subject: A general question about S/MIMEv2 & v3


Hello all,


Could someone give me a brief description of the new fonctionnalities that
were implemented in SMIME v3 ?

What are the main new capatibilities ?

Is this version already implemented in commercial products ?


Thanks a lot to all people who could answer me,

Regards,

L. Deffranne
Dexia Bank Belgium




Received: by ns.secondary.com (8.9.3/8.9.3) id IAA10236 for ietf-smime-bks; Mon, 30 Oct 2000 08:07:36 -0800 (PST)
Received: from luc.ab.org (mail.ab.org [209.112.11.37]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10231 for <[e-mail]>; Mon, 30 Oct 2000 08:07:34 -0800 (PST)
Received: from D00425 ([206.222.76.33]) by luc.ab.org (Netscape Messaging Server 3.6)  with SMTP id AAAD748; Mon, 30 Oct 2000 11:18:26 -0500
From: "Ozan Gonenc" <[e-mail]>
To: "Laurent Deffranne" <[e-mail]>, "ietf-smime" <[e-mail]>
Subject: RE: A general question about S/MIMEv2 & v3
Date: Mon, 30 Oct 2000 11:12:34 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello Laurent,

New functionalities include:
- Increased interoperability and support for digital signatures (V3 clients
support both DSA and RSA)
- V3 supports both D-H and RSA
- V3 supports secondary crypto algorithms
- D-H support is mandatory
- ESS (signed receipts, security labels, Secure MLAs, Signed certificates)
- V3 agent may generate separate D-H and DSS public/private key pairs on
behalf of the user

A number of software vendors are beginning to migrate to S/MIME v3 in phases
as the demand for extended security services increases.  Currently no
software vendors have incorporated "full" v3 compliance.

Hope this helps!

Cheers,

______________________________

Ozan Gonenc, B.Sc.
IT Security Consultant

AEPOS Technologies Corporation
[phone] x. 230 (Office)
[phone] (Fax)



-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Laurent Deffranne
Sent: October 30, 2000 09:28
To: ietf-smime
Subject: A general question about S/MIMEv2 & v3


Hello all,


Could someone give me a brief description of the new fonctionnalities that
were implemented in SMIME v3 ?

What are the main new capatibilities ?

Is this version already implemented in commercial products ?


Thanks a lot to all people who could answer me,

Regards,

L. Deffranne
Dexia Bank Belgium



Received: by ns.secondary.com (8.9.3/8.9.3) id GAA04363 for ietf-smime-bks; Mon, 30 Oct 2000 06:30:16 -0800 (PST)
Received: from mail.dexia.be (mail.dexia.be [193.91.97.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA04357 for <[e-mail]>; Mon, 30 Oct 2000 06:30:13 -0800 (PST)
Message-Id: <[e-mail]>
Date: 30 Oct 2000 15:28:09 +0100
From: Laurent Deffranne <[e-mail]>
To: ietf-smime <[e-mail]>
Subject: A general question about S/MIMEv2 & v3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello all,


Could someone give me a brief description of the new fonctionnalities that were implemented in SMIME v3 ?

What are the main new capatibilities ?

Is this version already implemented in commercial products ?


Thanks a lot to all people who could answer me,

Regards,

L. Deffranne
Dexia Bank Belgium


Received: by ns.secondary.com (8.9.3/8.9.3) id CAA17585 for ietf-smime-bks; Mon, 30 Oct 2000 02:54:31 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA17182; Mon, 30 Oct 2000 02:49:54 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA16164; Mon, 30 Oct 2000 12:01:15 +0100
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id LAA17102; Mon, 30 Oct 2000 11:55:00 +0100
Message-ID: <[e-mail]>
Date: Mon, 30 Oct 2000 11:55:00 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>
Subject: Call for papers: INFOSEC 2001
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA17186
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

INFOSEC 2001

15th exhibition and conference on the security of information systems and
communications

29.30.31 May - CNIT Paris-La Défense - FRANCE

CALL FOR PAPERS

Topics may be addressed from a technical, juridical or organizational
perspective. For 2001, the Programmes Committee will essentially, though not
exclusively, emphasise the following themes:

E-business, e-commerce - Insurance coverage for information systems -
Personal data: risks, means of protection - Competitive Intelligence (CI)
and counter-CI - Crisis management - Law : digital signature - Employees
control - Digital evidence and computer forensic - Specific product security
(NT, Linux, Oracle, etc.) - etc.

PROGRAMMES COMMITTEE

President: Pascal LOINTIER, ACE Insurance

Members: Prof. Danilo BRUSCHI, Université de Milan, Italie - Michèle
COPITET, EGONA CONSULTING - Michel DUPUY, SGDN/DCSSI - Cert A - Paul
GRASSART, CLUSIF - Frédéric HUYNH, ARTHUR ANDERSEN - Jean-Philippe JOUAS,
2SI - Me Bruno P. LANGLOIS, ALAIN BENSOUSSAN - AVOCATS - Patrick LAUTIER,
CLUSIF - Robert LONGEON, CNRS - Pierre-Marie LORANG, THOMSON CSF-DETEXIS -
Marie-Christine MARTEL, SGDN/DCSSI - Denis PINKAS, BULL - Paul RICHY, FRANCE
TELECOM - BR/DACR - Philippe ROSE, LE MONDE  - INFORMATIQUE - Stéphane
ROUHIER, CIGREF - Serge SAGHROUNE, ACCOR - Paul TRESCASES, GIE Cartes
Bancaires - Marcel VIGOUROUX, OCLCTIC

Organisation: Maryse DELERIS, M.C.I.

Sponsorship of CLUSIF ([e-mail]) Club de la Sécurité des
Systèmes d'Information Français and SGDN Premier Ministre - Direction
Centrale de la Sécurité des Systèmes d'Information (DCSSI).

DEADLINE TO SUBMIT A PROPOSAL : 31.12.2000

PRACTICAL INFORMATION

Authors have to send their proposal to M.C.I. (letter, fax or e-mail:
[e-mail]) by December 31st, 2000: an abstract (maximum of 3
pages) indicating: TITLE of the subject - and complete address of author(s)

At the end of January 2001, authors will receive the Programmes Committee's
decision. Selected authors will have to send the paper (following detailed
instructions) by February 25th, 2001 to be reviewed and definitively
accepted. Authors will have to certify their paper will not be published
prior to May 31st, 2001. Overtly " commercial " presentations are
inappropriate. 

Free admission offered for speakers (congress and exhibition).

INFORMATION  & ORGANISATION
M.C.I. - Manifestations & Communications Internationales
19 Rue d'Athènes - 75009 PARIS - FRANCE
Tél. : [phone] - Fax : [phone]
E-mail : [e-mail] - 
Web : http://www.mci-salons.fr/infosec


Received: by ns.secondary.com (8.9.3/8.9.3) id DAA20691 for ietf-smime-bks; Fri, 27 Oct 2000 03:32:44 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA20687 for <[e-mail]>; Fri, 27 Oct 2000 03:32:41 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05538; Fri, 27 Oct 2000 06:38:34 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-password-03.txt
Date: Fri, 27 Oct 2000 06:38:34 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Password-based Encryption for S/MIME
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-smime-password-03.txt
	Pages		: 11
	Date		: 26-Oct-00
	
The Cryptographic Message Syntax data format doesn't currently
contain any provisions for password-based data encryption.  This
document provides a method of encrypting data using user-supplied
passwords and, by extension, any form of variable-length keying
material which isn't necessarily an algorithm-specific fixed-format
key.

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

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-password-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-password-03.txt

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

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

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id DAA20683 for ietf-smime-bks; Fri, 27 Oct 2000 03:32:39 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA20679 for <[e-mail]>; Fri, 27 Oct 2000 03:32:37 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05510; Fri, 27 Oct 2000 06:38:30 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-compression-02.txt
Date: Fri, 27 Oct 2000 06:38:29 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Compressed Data Content Type for S/MIME
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-smime-compression-02.txt
	Pages		: 4
	Date		: 26-Oct-00
	
The Cryptographic Message Syntax data format doesn't currently
contain any provisions for compressing data before processing it.
Compressing data before transmission provides a number of advantages
including the elimination of data redundancy which could help an
attacker, speeding up processing by reducing the amount of data to be
processed by later steps such as signing or encryption, and reducing
overall message size. Although there have been proposals for adding
compression at other levels (for example at the MIME or SSL level)
these don't address the problem of compression of CMS content unless
the compression is supplied by an external means (for example by
intermixing MIME and CMS).  This document defines a format for using
compressed data as a CMS content type.

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

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-compression-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-compression-02.txt

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA02543 for ietf-smime-bks; Thu, 26 Oct 2000 14:44:26 -0700 (PDT)
Received: from wodc7mr3.ffx.ops.us.uu.net (wodc7mr3.ffx.ops.us.uu.net [192.48.96.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA02539 for <[e-mail]>; Thu, 26 Oct 2000 14:44:24 -0700 (PDT)
Received: from ieca.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP  (peer crosschecked as: 1Cust7.tnt16.rtm1.nl.uu.net [213.116.126.7]) id QQjmpz22454; Thu, 26 Oct 2000 21:49:48 GMT
Message-ID: <[e-mail]>
Date: Thu, 26 Oct 2000 23:49:33 +0200
From: "Bonatti, Chris" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Compressed Data
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms8A330C1AFB332164193A0EDC"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms8A330C1AFB332164193A0EDC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I should think that in many cases this value could be read from the operating
system, or otherwise known.  Since the size determination would be on the send side,
you're not generally counting data streaming in by the packet.

Of course, somebody will have an exception, but as long as it's optional it seems
like a good idea.

Chris B.


_________________________

[e-mail] wrote:

> [e-mail] wrote:
>
> >Forwarded from an external source for discussion in case anyone has any
> thoughts...
>
> >>>>As a heads up, the French and Norwegian delegates are interested in a
> >>>>change to the SMIME RFC. They have said they will propose separately an
> >>>>extension of the ID for a compressedData S/MIME content type. Extension
> >>>>consists of an additional field to indicate the uncompressed size of the
> >>>>encapsulated content. I don't know how soon this will happen.
> >>
> >>Hmm, I can see some problems with this, it assumes you know in advance how
> long
> >>the data stream will be which isn't always the case.  Adding an INTEGER
> >>OPTIONAL is pretty easy, but I wouldn't want to mandate its use because it'll
> >>cause problems for any streaming implementations (for example one of the uses
> I
> >>mentioned a while back was for securing EDI messages which can be ~100MB long,
> >>there's no way to tell in advance just how long they'll be because the systems
> >>processing the data can't afford to spool 100MB of data to disk while they
> wait
> >>for the end to appear).  I don't have a problem with adding something like
> >>this, I just wouldn't want to mandate it.
>
>    Couldn't the data be broken into smaller chunks (e.g. spooling 1 MB instead
> of 100MB at a time), and the uncompressed (and also compressed) size of each
> chunk be indicated?  The recipient could then add the uncompressed sizes of all
> the chunks to get the size of the original (uncompressed) data.  Of course, they
> would need a way to find all the size specifiers relatively quickly, and a count
> of all the chunks would be nice too...
>
>    Networking protocols like TCP/IP and IPX/SPX typically break large blocks of
> data up into manageable chunks, which they call "packets", but they also often
> have to deal with packets arriving (or not arriving) in arbitrary sequence,
> which (thank goodness) is not an issue in this case.
>
>    One thing I'm wondering is how the data compression algorithm will be
> specified.  I assume that new OIDs will have to be defined for each, if such
> don't already exist.
>
>    I am also wondering if there would be a way to generate clear-signed
> compressed content;  that is, if a way could be found to incorporate the
> compressed data into a MIME entity which is then signed as part of a
> multipart/signed message, and which could be read (and decompressed) by MIME
> parsers without S/MIME capability.  A simple mechanism would be to put the data
> into a .zip or .tar file attachment and specify that its content disposition is
> "inline", but I'm sure better ways are possible.

--------------ms8A330C1AFB332164193A0EDC
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIJ7AYJKoZIhvcNAQcCoIIJ3TCCCdkCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
B+4wggS4MIIEIaADAgECAhACOZkTH5mWlYOiMWNS0NA/MA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTIzMTAwMDAw
MFoXDTAwMTIzMDIzNTk1OVowggEXMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxHDAaBgNVBAMUE0NocmlzdG9waGVyIEJvbmF0dGkxIDAe
BgkqhkiG9w0BCQEWEWJvbmF0dGljQGllY2EuY29tMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB
ANKXlrz4lCtsKxQPevEUJ59yPcZpDmBoZnivM/oJtD1bUq0uUPml8eaZThkLVb3lx5Y3bHMe
iZUT86EDSuHBp78CAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYL
YIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9D
UFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQ
UyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCG
SAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNmMjA0NzAyOTI5ODc2
M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdkYTVkM2YyMTQxYmVh
YzkzYmNhZmY4YTBiYWU2ZGY1ZDcxMTQ5OWJhMmI4NDRmOWYzZWE0NTA2MDMGA1UdHwQsMCow
KKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEE
BQADgYEAPEGSRUMcSfb9eE0h/Bqqe0Q6h0YgoqFEL7MCsCFC3QOwvgNROksoF2+dJOCnOGum
vE3Pg6pyXJC02Qmt0qm2hmg3FLTNy0No9UnVld1NH0oejco+eeSfPO2xY0OFj1GojzeGZGfH
hmhB1V43k1Be90B9i/Vn4Tw6UsnhIjg9NgMwggMuMIICl6ADAgECAhEA0nYujRQMPX2yqCVd
r+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s
IEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB
dXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCBzDEXMBUGA1UEChMO
VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNV
BAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJ
QUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBT
dWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG9w0BAQEFAAOBjQAw
gYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV2TFBcHqBS7lIE1Yt
xwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/Gdr5FegPh7Yc48zG
mo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZIAYb4QgEBBAQDAgEG
MEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkq
hkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ43BuYDAeGW4UVag+5
SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1pElCY+zCphcPXVga
STyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAcYwggHCAgEBMIHhMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhACOZkTH5mWlYOiMWNS
0NA/MAkGBSsOAwIaBQCgfTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0wMDEwMjYyMTQ5MzNaMB4GCSqGSIb3DQEJDzERMA8wDQYIKoZIhvcNAwICASgwIwYJ
KoZIhvcNAQkEMRYEFAJ+UnetVuhIuNSkiQ9oe0jWidkAMA0GCSqGSIb3DQEBAQUABEBNY8CE
4LSkcKmpJ1DLP8yxj/70OLVed7TyphC9mBSeaDz3yw0VqtcApKcd0+iXL0RuJAHHR0Xa36wA
ZIaW2+Hn
--------------ms8A330C1AFB332164193A0EDC--



Received: by ns.secondary.com (8.9.3/8.9.3) id HAA20650 for ietf-smime-bks; Thu, 26 Oct 2000 07:03:56 -0700 (PDT)
Received: from aeposmail.aepos.com (aeposmail.aepos.com [209.112.11.5]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA20646 for <[e-mail]>; Thu, 26 Oct 2000 07:03:54 -0700 (PDT)
From: [e-mail]
Received: by aeposmail.aepos.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256984.004E0B9F ; Thu, 26 Oct 2000 10:12:27 -0400
X-Lotus-FromDomain: AEPOS
To: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 26 Oct 2000 10:12:39 -0400
Subject: re: Compressed Data
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] wrote:


>Forwarded from an external source for discussion in case anyone has any
thoughts...

>>>>As a heads up, the French and Norwegian delegates are interested in a
>>>>change to the SMIME RFC. They have said they will propose separately an
>>>>extension of the ID for a compressedData S/MIME content type. Extension
>>>>consists of an additional field to indicate the uncompressed size of the
>>>>encapsulated content. I don't know how soon this will happen.
>>
>>Hmm, I can see some problems with this, it assumes you know in advance how
long
>>the data stream will be which isn't always the case.  Adding an INTEGER
>>OPTIONAL is pretty easy, but I wouldn't want to mandate its use because it'll
>>cause problems for any streaming implementations (for example one of the uses
I
>>mentioned a while back was for securing EDI messages which can be ~100MB long,
>>there's no way to tell in advance just how long they'll be because the systems
>>processing the data can't afford to spool 100MB of data to disk while they
wait
>>for the end to appear).  I don't have a problem with adding something like
>>this, I just wouldn't want to mandate it.

   Couldn't the data be broken into smaller chunks (e.g. spooling 1 MB instead
of 100MB at a time), and the uncompressed (and also compressed) size of each
chunk be indicated?  The recipient could then add the uncompressed sizes of all
the chunks to get the size of the original (uncompressed) data.  Of course, they
would need a way to find all the size specifiers relatively quickly, and a count
of all the chunks would be nice too...

   Networking protocols like TCP/IP and IPX/SPX typically break large blocks of
data up into manageable chunks, which they call "packets", but they also often
have to deal with packets arriving (or not arriving) in arbitrary sequence,
which (thank goodness) is not an issue in this case.

   One thing I'm wondering is how the data compression algorithm will be
specified.  I assume that new OIDs will have to be defined for each, if such
don't already exist.

   I am also wondering if there would be a way to generate clear-signed
compressed content;  that is, if a way could be found to incorporate the
compressed data into a MIME entity which is then signed as part of a
multipart/signed message, and which could be read (and decompressed) by MIME
parsers without S/MIME capability.  A simple mechanism would be to put the data
into a .zip or .tar file attachment and specify that its content disposition is
"inline", but I'm sure better ways are possible.




Received: by ns.secondary.com (8.9.3/8.9.3) id TAA23454 for ietf-smime-bks; Wed, 25 Oct 2000 19:48:24 -0700 (PDT)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA23450 for <[e-mail]>; Wed, 25 Oct 2000 19:48:21 -0700 (PDT)
Received: from RHOUSLEY-PC.spyrus.com (dial07.spyrus.com [207.212.34.127]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id TAA04060; Wed, 25 Oct 2000 19:53:26 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 25 Oct 2000 22:17:43 -0400
To: <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Signature processing question
Cc: <[e-mail]>
In-Reply-To: <001801c03e53$a6f6be50$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The signature processing is the same.  The RSA-specific language was 
replaced with text that supports any signature algorithm.

Russ

At 09:17 AM 10/25/2000 +0200, Magnus Svensson wrote:
>I have a question regarding interoperability between S/MIME v2 and v3
>agents. After carefully reading through RFC2315 and RFC2630 I found a
>strange difference in the signature generation process for S/MIME v2 & v3.
>It seems to me that the signature in v2 is generated over the digest
>algorithm identifier + message digest while in v3 only over the message
>digest. Below is a reference to the RFCs:
>
>S/MIME v2:
>In PKCS#7 (RFC 2315), page 16, sec9.4 states:
>"The input to the digest-encryption process--the value supplied to the
>signer's digest-encryption algorithm--includes the result of the
>message-digesting process (informally, the "message digest") and the digest
>algorithm identifier (or object identifier). The result of the
>digest-encryption process is the encryption with the signer's private key of
>the BER encoding of a value of type DigestInfo:"
>
>S/MIME v3:
>In CMS (RFC2630), page 12, sec5.5 states:
>"The input to the signature generation process includes the result of the
>message digest calculation process and the signer's private key.
>The details of the signature generation depend on the signature algorithm
>employed.  The object identifier, along with any
>parameters, that specifies the signature algorithm employed by the signer is
>carried in the signatureAlgorithm field."
>
>Am I missing something or is it true that the signature processing differs?
>Lets hope I am wrong, otherwise that would mean:
>- There is no way a v2 MUA can verify the signature generated by a v3 MUA.
>- In order to be v2 compatible, a v3 MUA must try both signature processing
>techniques.
>
>If the above statements are correct, should not the CMS specification
>clarify that this is a backwards incompatible change from PKCS#7?
>Any help to clarify things in this matter is greatly appreciated.
>
>Regards,
>Magnus Svensson



Received: by ns.secondary.com (8.9.3/8.9.3) id SAA22063 for ietf-smime-bks; Wed, 25 Oct 2000 18:48:15 -0700 (PDT)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA22058 for <[e-mail]>; Wed, 25 Oct 2000 18:48:13 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id OAA29186 for <[e-mail]>; Thu, 26 Oct 2000 14:53:50 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97252523716719>; Thu, 26 Oct 2000 14:53:57 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: compressedData
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Thu, 26 Oct 2000 14:53:57 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Forwarded from an external source for discussion in case anyone has any
thoughts...

At 08:33 AM 10/14/2000 +0000, Peter Gutmann wrote:
>>This seems like an interesting suggestion.  What do you think?
>
>>>As a heads up, the French and Norwegian delegates are interested in a
>>>change to the SMIME RFC. They have said they will propose separately an
>>>extension of the ID for a compressedData S/MIME content type. Extension
>>>consists of an additional field to indicate the uncompressed size of the
>>>encapsulated content. I don't know how soon this will happen.
>
>Hmm, I can see some problems with this, it assumes you know in advance how long
>the data stream will be which isn't always the case.  Adding an INTEGER
>OPTIONAL is pretty easy, but I wouldn't want to mandate its use because it'll
>cause problems for any streaming implementations (for example one of the uses I
>mentioned a while back was for securing EDI messages which can be ~100MB long,
>there's no way to tell in advance just how long they'll be because the systems
>processing the data can't afford to spool 100MB of data to disk while they wait
>for the end to appear).  I don't have a problem with adding something like
>this, I just wouldn't want to mandate it.
>
>(Having said that, an indication of what the decompressed size info would be
> useful for would also be interesting, I can't think of much offhand where it'd
> be necessary but I haven't really given it too much thought).



Received: by ns.secondary.com (8.9.3/8.9.3) id CAA26456 for ietf-smime-bks; Wed, 25 Oct 2000 02:11:10 -0700 (PDT)
Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA26450 for <[e-mail]>; Wed, 25 Oct 2000 02:11:07 -0700 (PDT)
Received: from watson [129.27.152.142] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A4EB2D301E2; Wed, 25 Oct 2000 11:16:27 +0200
Received: from localhost [127.0.0.1] by watson (IAIK S/MIME Mapper 2.0beta3 22/March/2000); Wed, 25 Oct 2000 11:11:23 +0100
From: "Dieter Bratko" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: AW: Signature processing question
Date: Wed, 25 Oct 2000 11:11:23 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <001801c03e53$a6f6be50$[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

As implementing S/MIMEv2/v3, my interpretation is, that S/MIMEv3 (CMS) now
uses PKCS#1 RSA based signature algorithms (making the DigestInfo wrapping
itself) for RSA based signature creation. So -- for RSA signatures -- the
DigestInfo wrapping still is done and the signature creation process is
compatible to S/MIMEv2.

S/MIMEv2 (PKCS#7v1.5) uses the RSA encryption method and does the DigestInfo
wrapping outside (and therefore may not be used for, e.g., DSA).

Hope, this interpretation is right.

Regards,
Dieter Bratko

-----Ursprüngliche Nachricht-----
Von: [e-mail]
[mailto:[e-mail]]Im Auftrag von Magnus Svensson
Gesendet: Mittwoch, 25. Oktober 2000 09:18
An: [e-mail]
Betreff: Signature processing question


I have a question regarding interoperability between S/MIME v2 and v3
agents. After carefully reading through RFC2315 and RFC2630 I found a
strange difference in the signature generation process for S/MIME v2 & v3.
It seems to me that the signature in v2 is generated over the digest
algorithm identifier + message digest while in v3 only over the message
digest. Below is a reference to the RFCs:

S/MIME v2:
In PKCS#7 (RFC 2315), page 16, sec9.4 states:
"The input to the digest-encryption process--the value supplied to the
signer's digest-encryption algorithm--includes the result of the
message-digesting process (informally, the "message digest") and the digest
algorithm identifier (or object identifier). The result of the
digest-encryption process is the encryption with the signer's private key of
the BER encoding of a value of type DigestInfo:"

S/MIME v3:
In CMS (RFC2630), page 12, sec5.5 states:
"The input to the signature generation process includes the result of the
message digest calculation process and the signer's private key.
The details of the signature generation depend on the signature algorithm
employed.  The object identifier, along with any
parameters, that specifies the signature algorithm employed by the signer is
carried in the signatureAlgorithm field."

Am I missing something or is it true that the signature processing differs?
Lets hope I am wrong, otherwise that would mean:
- There is no way a v2 MUA can verify the signature generated by a v3 MUA.
- In order to be v2 compatible, a v3 MUA must try both signature processing
techniques.

If the above statements are correct, should not the CMS specification
clarify that this is a backwards incompatible change from PKCS#7?
Any help to clarify things in this matter is greatly appreciated.

Regards,
Magnus Svensson





Received: by ns.secondary.com (8.9.3/8.9.3) id AAA24343 for ietf-smime-bks; Wed, 25 Oct 2000 00:14:09 -0700 (PDT)
Received: from marcellus.cost.se (marcellus.cost.se [195.100.88.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA24339 for <[e-mail]>; Wed, 25 Oct 2000 00:14:06 -0700 (PDT)
Received: from nelson (nelson.cost.se [10.0.0.38]) by marcellus.cost.se (8.9.3/8.9.3) with SMTP id IAA19578 for <[e-mail]>; Wed, 25 Oct 2000 08:16:28 +0100 (MET)
Reply-To: <[e-mail]>
From: "Magnus Svensson" <[e-mail]>
To: <[e-mail]>
Subject: Signature processing question
Date: Wed, 25 Oct 2000 09:17:35 +0200
Message-ID: <001801c03e53$a6f6be50$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have a question regarding interoperability between S/MIME v2 and v3
agents. After carefully reading through RFC2315 and RFC2630 I found a
strange difference in the signature generation process for S/MIME v2 & v3.
It seems to me that the signature in v2 is generated over the digest
algorithm identifier + message digest while in v3 only over the message
digest. Below is a reference to the RFCs:

S/MIME v2:
In PKCS#7 (RFC 2315), page 16, sec9.4 states:
"The input to the digest-encryption process--the value supplied to the
signer's digest-encryption algorithm--includes the result of the
message-digesting process (informally, the "message digest") and the digest
algorithm identifier (or object identifier). The result of the
digest-encryption process is the encryption with the signer's private key of
the BER encoding of a value of type DigestInfo:"

S/MIME v3:
In CMS (RFC2630), page 12, sec5.5 states:
"The input to the signature generation process includes the result of the
message digest calculation process and the signer's private key.
The details of the signature generation depend on the signature algorithm
employed.  The object identifier, along with any
parameters, that specifies the signature algorithm employed by the signer is
carried in the signatureAlgorithm field."

Am I missing something or is it true that the signature processing differs?
Lets hope I am wrong, otherwise that would mean:
- There is no way a v2 MUA can verify the signature generated by a v3 MUA.
- In order to be v2 compatible, a v3 MUA must try both signature processing
techniques.

If the above statements are correct, should not the CMS specification
clarify that this is a backwards incompatible change from PKCS#7?
Any help to clarify things in this matter is greatly appreciated.

Regards,
Magnus Svensson



Received: by ns.secondary.com (8.9.3/8.9.3) id RAA18167 for ietf-smime-bks; Tue, 24 Oct 2000 17:00:57 -0700 (PDT)
Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA18163; Tue, 24 Oct 2000 17:00:56 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010422b61bd3b15515@[165.227.249.17]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 24 Oct 2000 17:06:36 -0700
To: [e-mail], [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-smime-examples-04.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 6:10 AM -0400 10/24/00, [e-mail] wrote:
>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-04.txt
>	Pages		: 8
>	Date		: 23-Oct-00

It's too bad that there is no emoticon for "really embarrassed". I 
put out this draft with essentially no changes from the -03 because 
the -03 expired a long time ago and I have completely ignored it. 
Well, I ignored in between feeling bad about it. But you get the 
picture.

Because I had also lamely filed the comments people had sent me a 
year ago about -03 into different folders, I am not sure what need to 
be fixed. I know that much does need to be fixed, but I am not sure 
what. Please send (or, probably, re-send) all comments to me and the 
[e-mail] list. And I really, really promise to get 
-05 out before the cutoff for the San Diego IETF.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA21281 for ietf-smime-bks; Tue, 24 Oct 2000 03:05:15 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA21274 for <[e-mail]>; Tue, 24 Oct 2000 03:05:10 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02049; Tue, 24 Oct 2000 06:10:48 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-examples-04.txt
Date: Tue, 24 Oct 2000 06:10:47 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

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

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

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

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-examples-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-examples-04.txt

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

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

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id IAA14242 for ietf-smime-bks; Mon, 23 Oct 2000 08:36:21 -0700 (PDT)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14234 for <[e-mail]>; Mon, 23 Oct 2000 08:36:19 -0700 (PDT)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id IAA11044 for <[e-mail]>; Mon, 23 Oct 2000 08:41:20 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 23 Oct 2000 11:41:14 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Fwd: RE: Use of the IDEA Encryption Algorithm in CMS
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This should have been posted to the S/MIME WG list, not the PKIX WG mail list.

Russ


>From: "Teiwes, Stephan (iT_SEC)" <[e-mail]>
>To: "'Maxim Masiutin'" <[e-mail]>,
>         "Teiwes, Stephan (iT_SEC)"
>         <[e-mail]>,
>         "Hartmann, Peter  (iT_SEC)"
>         <[e-mail]>,
>         [e-mail], [e-mail]
>Subject: RE: Use of the IDEA Encryption Algorithm in CMS
>Date: Mon, 23 Oct 2000 16:52:21 +0200
>X-Mailer: Internet Mail Service (5.5.2448.0)
>List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
>List-ID: <ietf-pkix.imc.org>
>List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
>
>Dear Mr. Masuitin,
>
>thanks a lot. We'll consider your comments and try to improve the draft
>accordingly.
>
>*Stephan Teiwes
>iT_Security AG
>www.it-sec.com
>
>-----Original Message-----
>From: Maxim Masiutin [mailto:[e-mail]]
>Sent: Montag, 23. Oktober 2000 16:41
>To: [e-mail]; [e-mail];
>[e-mail]; [e-mail]
>Subject: Use of the IDEA Encryption Algorithm in CMS
>
>
>Dear authors of "Use of the IDEA Encryption Algorithm in CMS" draft!
>
>
>I have a question about following paragraph in
>draft-ietf-smime-idea-07.txt:
>
>-----------
>If IV is specified as above, it MUST be used as initial vector. In
>this case, the ciphertext MUST NOT include the initial vector. If
>IV is not specified, the first 64 bits of the ciphertext MUST be
>considered as the initial vector. However, this alternative of not
>including the IV SHOULD NOT be applied in CMS or S/MIME.
>-----------
>
>   The last sentence:
>
>"this alternative of not including the IV [into "iv OCTET STRING" of
>IDEA-CBCPar|into the first 64 bits of the ciphertext] SHOULD NOT be
>applied in CMS or S/MIME.
>
>
>Could you please expand this sentence by adding one of the short
>explanations that I've proposed?
>
>I do also have a question about the following paragraph:
>
>------------
>The SMIMECapability SEQUENCE representing the IDEA symmetric
>encryption algorithm MUST include the IDEA-CBC OID in the capabilityID
>field and the parameters field MUST be absent. The SMIMECapability
>SEQUENCE for IDEA encryption SHOULD be included in the symmetric
>encryption algorithms portion of the SMIMECapabilities list. The
>SMIMECapability SEQUENCE representing IDEA MUST be DER-encoded as
>follows: 300D 060B 2B06 0104 0181 3C07 0101 02.
>------------
>
>   Why don't you give ASN.1 notation of SMIMECapability SEQUENCE
>   representing IDEA as well as DER-encoded value? Please add ASN.1
>   notation to the draft. Also, please clarify the byte order.
>
>   And a test sample of CMS-message with IDEA will help me a lot!
>
>   Thank you in advance.
>
>
>
>--
>Maxim Masiutin,
>Software Engineer
>RIT Research Labs  http://www.ritlabs.com/



Received: by ns.secondary.com (8.9.3/8.9.3) id IAA02651 for ietf-smime-bks; Thu, 19 Oct 2000 08:44:49 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA02646 for <[e-mail]>; Thu, 19 Oct 2000 08:44:48 -0700 (PDT)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id IAA11131; Thu, 19 Oct 2000 08:49:53 -0700 (PDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 2984 on CAST-128 in CMS
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 19 Oct 2000 08:49:53 -0700
From: RFC Editor <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 2984

        Title:	    Use of the CAST-128 Encryption Algorithm in CMS 
        Author(s):  C. Adams
        Status:     Standards Track
	Date:       October 2000
        Mailbox:    [e-mail]
        Pages:      6
        Characters: 11591
        Updates/Obsoletes/SeeAlso:  None

        I-D Tag:    draft-ietf-smime-cast-128-02.txt

        URL:        ftp://ftp.isi.edu/in-notes/rfc2984.txt


This document specifies how to incorporate CAST-128 (RFC2144) into
the S/MIME Cryptographic Message Syntax (CMS) as an additional
algorithm for symmetric encryption.  The relevant OIDs and processing
steps are provided so that CAST-128 may be included in the CMS
specification (RFC2630) for symmetric content and key encryption.

This document is a product of the S/MIME Mail Security Working Group
of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

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

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[e-mail]"

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

RETRIEVE: rfc
DOC-ID: rfc2984

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc2984.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

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

--OtherAccess--
--NextPart--


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA29527 for ietf-smime-bks; Sat, 14 Oct 2000 08:05:06 -0700 (PDT)
Received: from dns.flour-mills.com.kw ([168.187.154.98]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29522 for <[e-mail]>; Sat, 14 Oct 2000 08:05:03 -0700 (PDT)
Message-Id: <[e-mail]>
Received: from host (1Cust254.tnt1.providence.ri.da.uu.net [63.21.181.254]) by dns.flour-mills.com.kw with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id T36JG0T3; Sat, 14 Oct 2000 18:07:58 +0100
From: "Charlie Wenscot" <[e-mail]>
Subject: Your Status # 376
To: list94f
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3
Mime-Version: 1.0
Date: Sat, 14 Oct 2000 07:04:54 -0500
Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a MIME Message

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

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

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


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

<!doctype html public "-//w3c//dtd html 4=2E0
 transitional//en">
 <html>
 <head>
    
    <title>Executive Guild Membership
 ApplicationResponse-O-Matic Form</title>
 </head>
 <body text=3D"#808080" bgcolor=3D"#FFCC99"
 link=3D"#800040" vlink=3D"#FF0000" alink=3D"#8080C0">
 <p><font color=3D"#000000">Dear Professional,<br>
 <br>
 You have been selected as a potential candidate for a free<br>
 listing in the 2000 - 2001 Edition of the International Executive<br>
 Guild Registry=2E<br>
 <br>
 Please accept our congratulations for this coveted honor=2E<br>
 <br>
 As this edition is so important in view of the new millennium, the<br>
 International Executive Guild Registry will be published in two<br>
 different formats; the searchable CD-ROM and the Online Registry=2E<br>
 <br>
 Since inclusion can be considered recognition of your career position<br>=

 and professionalism, each candidate is evaluated in keeping with high<br>=

 standards of individual achievement=2E In light of this, the Internationa=
l<br>
 Executive Guild thinks that you may make an interesting biographical<br>
 subject=2E<br>
 <br>
 We look forward to your inclusion and appearance in the International<br>=

 Executive Guild's Registry=2E Best wishes for your continued success=2E<b=
r>
 <br>
 International Executive Guild<br>
 Listing Dept=2E<br>
 <br>
 </font></p>
 <p>
 <hr WIDTH=3D"100%">
 <p align=3D"center"><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>
 </p>
 <hr WIDTH=3D"100%">
 <table WIDTH=3D"695" >
 <caption><script language=3D"JavaScript">
 
 <!--
 function validate_form() {
   validity =3D true; // assume valid
   if (!check_empty(document=2Eform=2Ebusphone=2Evalue))
         { validity =3D false; alert('Day Time
 Phone field is empty!'); }
     if (validity)
         alert ("Thank you for your registration!
 "
                 + "Your form is now being passed
 to your browser's "
                 + "Mail Delivery Sub-System for
 NORMAL"
                 + " NON-ENCRYPTED email
 delivery=2E"
                 + "  All email addresses are
 removed from our system"
                 + " 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:bbt9k@verizonmail=2Ecom?SUBJECT=3DInternet Lead"
  enctype=3D"text/plain"
  onSubmit=3D"return validate_form()"></caption>
 
 <tr>
 <td></td>
 </tr>
 
 <tr>
 <td VALIGN=3DTOP COLSPAN=3D"2">
 <center><b><i><font color=3D"#000000"><font
 size=3D+3>International Executive Guild</font></font></i></b>
 <br><b><font color=3D"#000000"><font
 size=3D+2>Registration Form</font></font></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
 color=3D"#000000"><font size=3D+0>Please
 fill out this form if you would like to be
 included on The International
 Executive Guild, 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
 on The International Executive Guild=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
 color=3D"#000000"><font size=3D-1>Your
 Name</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250" name=3D"Name"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Your
 Company</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250"
 name=3D"Company"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Title</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250"
 name=3D"Title"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Address</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250"
 name=3D"Address"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>City</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250" name=3D"City"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>State
 or Province</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"12" maxlength=3D"50" name=3D"State"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Country</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><select
 NAME=3D"Country" Size=3D"1"><option SELECTED><font
 color=3D"#000000">USA<option
 SELECTED>Canada</font></select></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=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" value size=3D"12" maxlength=3D"50"
 name=3D"Zip"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Day
 Time Telephone</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"22" maxlength=3D"50"
 name=3D"busphone"></td>
 </tr>
 
 <tr>
 <td>
 <div align=3Dright><b><font
 face=3D"Arial,Helvetica"><font
 color=3D"#000000"><font size=3D-1>Home
 Phone</font></font></font></b></div>
 </td>
 
 <td><input type=3D"text" value size=3D"22"
 maxlength=3D"50" name=3D"homephone"><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"#000000"><font size=3D-
 1>Email</font></font></font></b></div>
 </td>
 
 <td><input type=3D"text" value size=3D"50"
 maxlength=3D"100" name=3D"Email"></td>
 </tr>
 
 <tr>
 <td></td>
 
 <td></td>
 </tr>
 </table>
 
 <center>
 <p>
 <hr WIDTH=3D"100%"><b><font
 face=3D"ARIAL,HELVETICA"><font
 color=3D"#000000"><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%" >
 <tr>
 <td ALIGN=3DRIGHT VALIGN=3DTOP WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Your
 Business</font></font></font></b></td>
 
 <td>
 <div align=3Dright><input type=3D"text" value
 size=3D"50" maxlength=3D"200"
 name=3D"business"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>(Financial
 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,helvetica"><font
 color=3D"#000000"><font size=3D-1>Type
 of Organization</font></font></font></b></td>
 
 <td>
 <div align=3Dright><input type=3D"text" value size=3D"50" maxlength=3D"25=
0"
 name=3D"Orgtype"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font size=3D-1>(M=
fg,
 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"#000000"><font
 size=3D-1>Your
 Business Expertise</font></font></font></b></div>
 </td>
 
 <td>
 <div align=3Dright><input type=3D"text" value size=3D"50" maxlength=3D"25=
0"
 name=3D"expertise"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>(Corp=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,
 Mortgage
 Banking, etc=2E)</font></font></font></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT VALIGN=3DTOP WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Major
 Product Line</font></font></font></b></td>

 <td>
 <div align=3Dright><input type=3D"text" value size=3D"50" maxlength=3D"25=
0"
 name=3D"product"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>(Integrated
 Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components,
 
 Snack Foods, etc=2E)</font></font></font></td>
 </tr>
 </table></center>
 
 <center>
 <p><input NAME=3D"submit" TYPE=3D"submit" VALUE=3D" Submit By E-Mail "><i=
nput
 NAME=3D"reset" TYPE=3D"reset" VALUE=3D" Clear Form "></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 de=
livery
 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"#000000"><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:bb28b@usa=2Enet?subject=3Dremove">Click
 Here</a></font></font></b></center>
 
 </body>
 </html>

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

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





Received: by ns.secondary.com (8.9.3/8.9.3) id KAA01380 for ietf-smime-bks; Fri, 13 Oct 2000 10:08:09 -0700 (PDT)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA01374 for <[e-mail]>; Fri, 13 Oct 2000 10:08:08 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.205]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id KAA13174 for <[e-mail]>; Fri, 13 Oct 2000 10:12:18 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 13 Oct 2000 13:02:36 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: FYI: SHA-2, AES
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim Polk posted this to the IETF Working Group chairs and the PKIX Working 
Group.  I am forwarding it to this list to make sure everyone got the word.

Russ

= = = = = = = = = =

NIST has just posted a white paper that specifies hashing algorithms 
(SHA-256, SHA-384, and SHA-512) that are intended to provide security 
similar to that of the three AES key sizes. Information can be found at 
<http://www.nist.gov/sha/>.

These algorithms "will be proposed in a draft Federal Information 
Processing Standard (FIPS) in 2001. These algorithms are being made 
available for information purposes prior to the publication of the draft 
FIPS. SHA-256 is a 256-bit hash function that is intended to provide 128 
bits of security against collision attacks, and SHA-512 is a 512-bit hash 
function that is intended to provide 256 bits of security. A 384-bit hash 
may be obtained by truncating the SHA-512 output."

The web site has the NIST contact points.

One side note about AES: http://csrc.nist.gov/csor/algorithms.htm contains 
the object identifiers and ASN.1 type definitions for AES parameters for 
protocols built on ASN.1.  The OIDs for the new hash algorithms will follow 
next week.

Thanks,

Tim Polk



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA09569 for ietf-smime-bks; Thu, 12 Oct 2000 10:16:55 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA09564; Thu, 12 Oct 2000 10:16:53 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <TRNYXPMB>; Thu, 12 Oct 2000 13:24:06 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "Pawling, John" <[e-mail]>
Subject: v1.8 S/MIME Freeware Library Now Available
Date: Thu, 12 Oct 2000 13:20:50 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

Getronics Government Solutions (GGS) (formerly Wang Government Services) has
delivered Version 1.8 of the S/MIME Freeware Library (SFL) source code.  The
SFL source code files are freely available to everyone from the Fortezza
Developer's S/MIME Page
<http://www.armadillo.huntsville.al.us/software/smime>.  

The SFL implements the IETF S/MIME v3 RFC 2630 Cryptographic Message 
Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS) specifications. 
It also implements portions of the RFC 2633 Message Specification and 
RFC 2632 Certificate Handling document.  When used in conjunction with
the Crypto++ v3.2 freeware library, the SFL implements the RFC 2631 
Diffie-Hellman (D-H) Key Agreement Method specification.  It has been 
successfully tested using the MS Windows NT/95/98, Linux and Solaris 2.7
operating 
systems.  Further enhancements, ports and testing of the SFL are still in 
process.  Further releases of the SFL will be provided as significant 
capabilities are added. 

The SFL has been successfully used to sign, verify, encrypt and decrypt
CMS/ESS 
objects using: S/MIME v3 mandatory-to-implement algorithms (DSA, E-S D-H,
3DES) 
provided by the Crypto++ v3.2 library; RSA suite of algorithms provided by
the 
RSA BSAFE v4.2 and Crypto++ v3.2 libraries; and Fortezza suite of algorithms

provided by the Fortezza Crypto Card.  The v1.8 SFL uses the v1.3 R4
Enhanced SNACC  
ASN.1 Library to encode/decode objects. The v1.8 SFL release includes: SFL
High-
level library; Free (a.k.a. Crypto++) Crypto Token Interface Library (CTIL);

BSAFE CTIL; Fortezza CTIL; SPEX/ CTIL; PKCS #11 CTIL (still being tested); 
v1.3 R4 Enhanced SNACC ASN.1 Compiler and Library; test utilities; test
drivers
and test data.  All CTILs were tested as Dynamically Linked Libraries (DLL)
using MS Windows.  The Fortezza, BSAFE and Crypto++ CTILs were tested with
the respective security libraries as shared objects using Linux and Solaris
2.7.  

The SFL has been successfully used to exchange signedData and envelopedData 
messages with the Microsoft (MS) Internet Explorer Outlook Express v4.01 and

Netscape Communicator 4.X S/MIME v2 products.  Signed messages have been 
exchanged with the RSA S/MAIL, WorldTalk and Entrust S/MIME v2 products. 

The SFL has also been used to perform S/MIME v3 interoperability testing
with 
Microsoft that exercised the majority of the features specified by RFCs
2630, 
2631 and 2634.  This testing included the RSA, mandatory S/MIME V3 and
Fortezza 
suites of algorithms.  We used the SFL to successfully process all of the 
SFL-supported sample data included in the S/MIME WG "Examples of S/MIME
Messages"
document.  We have also performed limited S/MIME v3 testing with Baltimore
and
Entrust.  

The following enhancements are included in the v1.8 SFL release (compared
with 
the v1.7 release):

1) Tested using common v1.3 R4 Enhanced SNACC ASN.1 Library, v1.8 CTILs and
LIBCERT libraries shared with the v1.4 Access Control Library (ACL) and v1.8
Certificate Management Library (CML).

2) Added OpenSSL-based PKCS #12 create/read capabilities that can be used in
conjunction with any of the CTILs.  For example, we used this capability to
import Microsoft-created PKCS #12 files directly into the Crypto++ CTIL.
CTIL logins optionally accept a PCKS #12 file to obtain both the private key
and certificate.  

3) Enhanced PKCS #11 (v2.1) CTIL tested with the 30 June 2000 production
version of the Litronic Maestro v1.0 crypto library.  We successfully used
the PKCS #11 CTIL and v1.0 Maestro library to sign/verify and
encrypt/decrypt S/MIME v3 messages using a Fortezza Card.  We performed
signed and encrypted interoperability testing between the PKCS #11 and
Fortezza CTILs.  We also performed signed interoperability testing between
the PKCS #11 and Crypto++ CTILs using DSA.  

4) Enhanced SFL and LIBCERT, so LIBCERT can be used independently of SFL
(i.e. without SFL source code).  

5) Corrected bugs in Fortezza and SPEX/ CTILs.  

6) Corrected bugs in Enhanced SNACC ASN.1 Library that caused BIT STRINGs
and DEFAULT values to be improperly ASN.1 encoded using the Distinguished
Encoding Rules

7) Performed regression testing to ensure that aforementioned enhancements
did 
not break existing SFL functionality.

We also delivered updated SFL Application Programming Interface (API) and
CTIL API documents. 

We are still in the process of enhancing and testing the SFL.  Future
releases 
will include: additional PKCS #11 CTIL testing; additional SPEX/ CTIL
testing; finish CertificateBuilder command line utility; enhancing
CertificateBuilder to support creation of Attribute Certificates; add MIME
support for test drivers; add "Certificate Management 
Messages over CMS" ASN.1 encode/decode functions; add enhanced test
routines; 
bug fixes; support for other crypto APIs (possible); and support for other
operating systems. 

The SFL is developed to maximize portability to 32-bit operating 
systems.  In addition to testing on MS Windows, Linux and Solaris 2.7, we
plan to port 
the SFL to the following operating systems: HP/UX 11, IBM AIX 3.2 
(possibly), SCO 5.0 (possibly) and Macintosh (possibly).

The following SFL files are available from the Fortezza Developer's S/MIME
Page:

1) SFL Documents: Fact Sheet, Software Design Description, API, CTIL API,
Software Test Description, Implementers Guide, Overview Briefing and Public
License.
     
2) smimeR1.8.tar.gz:  Source code, MS Windows NT/95/98/2000 project files
and Unix makefiles for SFL Hi-Level library.

3) snacc13r4rn.tar.gz: Source code, MS Windows NT/95/98/2000 project files
and Unix makefiles for v1.3 R4 Enhanced SNACC ASN.1 Compiler and Library.
Source code is compilable for Linux, Solaris 2.7 and MS Windows
NT/95/98/2000 that has been enhanced by GGS to implement the Distinguished
Encoding Rules.  This file includes a sample test project demonstrating the
use of the SNACC classes.

4) smCTIR1.8.tar.gz:  Source code, MS Windows NT/95/98/2000 project files
and Unix makefiles for the following CTILs: Test (no crypto), Crypto++,
BSAFE, Fortezza, SPEX/ and PKCS #11. 

5) smLibCR1.8.tar.gz: Source code, MS Windows NT/95/98/2000 project files
and Unix makefiles for the LIBCERT library that provides ASN.1 and
certificate processing services used by the SFL, ACL and CML.

6) smTest1.8.tar.gz: Source code, MS Windows NT/95/98/2000 project files and
Unix makefiles for test drivers used to test the SFL.  This file also
includes sample CMS/ESS test data and test X.509 Certificates.  This file
also includes test utilities to create X.509 Certificates that each include
a D-H, DSA or RSA public key.  

7) csmime.mdl contains SFL Class diagrams created using Microsoft
Visual Modeler (comes with MS Visual Studio 6.0, Enterprise Tools).
The file can also be viewed using Rational Rose C++ Demo 4.0
45 day evaluation copy which can be obtained from
<http://www.rational.com/uml/resources/practice_uml/index.jtmpl>.
Not all classes are documented in the MDL file at this time.

All source code for the SFL is being provided at no cost and with no 
financial limitations regarding its use and distribution. 
Organizations can use the SFL without paying any royalties or 
licensing fees.  GGS is developing the SFL under contract to the U.S. 
Government.  The U.S. Government is furnishing the SFL source code at no 
cost to the vendor subject to the conditions of the "SFL Public 
License" available from the Fortezza Developer's S/MIME Page.

On 14 January 2000, the U.S. Department of Commerce, Bureau of 
Export Administration published a new regulation implementing an update to
the U.S. Government's encryption export policy 
<http://www.bxa.doc.gov/Encryption/Default.htm>.  In accordance with the 
revisions to the Export Administration Regulations (EAR) of 14 Jan 2000,
the downloading of the SFL source code is not password controlled.

The SFL is composed of a high-level library that performs generic CMS 
and ESS processing independent of the crypto algorithms used to 
protect a specific object.  The SFL high-level library makes calls to 
an algorithm-independent CTIL API.  The underlying, external crypto
token libraries are not distributed as part of the SFL 
source code. The application developer must independently obtain these 
libraries and then link them with the SFL.  For example, the SFL can be 
used with the freeware Crypto++ library to obtain 3DES, D-H, RSA and DSA.
To use the SFL with Crypto++ the vendor must download the Crypto++ freeware 
library from the Crypto++ Web Page
<http://www.eskimo.com/~weidai/cryptlib.html>
and then compile it with the GGS-developed Crypto++ CTIL source code.  
 
The Internet Mail Consortium (IMC) has established an SFL web page
<http://www.imc.org/imc-sfl>.  The IMC has also established an SFL
mail list which is used to: distribute information regarding SFL
releases; discuss SFL-related issues; and provide a means for SFL
users to provide feedback, comments, bug reports, etc.  Subscription
information for the imc-sfl mailing list is at the IMC web site
listed above.

All comments regarding the SFL source code and documents are welcome.  This
SFL release announcement was sent to several mail lists, but please send all
messages regarding the SFL to the imc-sfl mail list ONLY.  Please do not
send messages regarding the SFL to any of the IETF mail lists.  We will
respond to all messages sent to the imc-sfl mail list.

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


Received: by ns.secondary.com (8.9.3/8.9.3) id OAA07550 for ietf-smime-bks; Wed, 11 Oct 2000 14:34:18 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA07546 for <[e-mail]>; Wed, 11 Oct 2000 14:34:17 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <TRNYXMRB>; Wed, 11 Oct 2000 17:41:28 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: RE: ESS Questions
Date: Wed, 11 Oct 2000 17:38:23 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

It seems that mkicksee has pointed out an error in RFC 2634.  It seems that
the second sentence should be deleted from Section 4.2.3.2 Processing for
SignedData, bullet 2 as follows:

   2. If the outermost SignedData layer includes a signed
      mlExpansionHistory attribute, the MLA checks for an expansion loop
      as described in the "Detecting Mail List Expansion Loops" section,
      then go to step 3. If the outermost SignedData layer does not
      include a signed mlExpansionHistory attribute, the MLA signs the
      whole message (including this outermost SignedData layer that
      doesn't have an mlExpansionHistory attribute), and delivers the
      updated message to mail list members to complete MLA processing.

Example 5 in section 4.2.1 indicates that the MLA would continue processing
the layers of the received message if the outermost SignedData layer does
not include a signed mlExpansionHistory attribute, so that seems to
contradict the second sentence of Section 4.2.3.2, bullet 2.

As best I can remember, the second sentence of Section 4.2.3.2, bullet 2 was
included in RFC 2634 to address the case in which an MLA is processing a
message composed of a single signedData layer.  However, it seems that
section 3.3 addresses this case, so the second sentence of Section 4.2.3.2,
bullet 2 is not needed.

Unless somebody objects, I recommend that the second sentence should be
deleted from Section 4.2.3.2, bullet 2 and that the flow chart should be
updated accordingly.

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



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Thursday, October 05, 2000 1:54 PM
To: [e-mail]
Subject: RE: ESS Questions




>4.2.3.2 Processing for SignedData
>
>Q.  Step 2 of this process has been changed from the
>Internet draft version (draft-ietf-smime-ess-09.txt).  It
>seems that now if the "outer" signed data layer is absent
>or does not contain an mlExpansionHistory attribute, the
>MLA simply adds a new outer signed layer, lists itself in
>the mlExpansionHistory attribute, and sends the message to
>the recipients.  It would no longer expand any encrypted
>data for the recipients.  If someone sent a message that
>was encrypted then signed to the MLA, the recipients would
>not be able to decrypt it.  Have I misread this paragraph?
>
>[JSP: You have misinterpreted the paragraph.]

Did I also misinterpret the flowchart (quoted below)?

   1. Has a valid signature?
          YES -> 2.
          NO  -> STOP.
   2. Does outermost SignedData layer contain mlExpansionHistory?
          YES -> Check it, then -> 3.
          NO  -> Sign message (including outermost SignedData that
                 doesn't have mlExpansionHistory), deliver it, STOP.

   It seems clear that the MLA would not expand encrypted data unless the
outer
signature is either absent or that of an MLA.



Received: by ns.secondary.com (8.9.3/8.9.3) id NAA05865 for ietf-smime-bks; Wed, 11 Oct 2000 13:22:20 -0700 (PDT)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05860 for <[e-mail]>; Wed, 11 Oct 2000 13:22:19 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.205]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id NAA11084 for <[e-mail]>; Wed, 11 Oct 2000 13:26:41 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 11 Oct 2000 16:23:22 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Agenda for San Diego
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It is time to start putting together the agenda for the S/MIME WG meeting 
in San Diego.  I have requested a two hour slot.  Let me know if you would 
like a portion of that 2 hours.

Russ



Received: by ns.secondary.com (8.9.3/8.9.3) id UAA17184 for ietf-smime-bks; Sun, 8 Oct 2000 20:10:59 -0700 (PDT)
Received: from mail1.mia.bellsouth.net (mail1.mia.bellsouth.net [205.152.144.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA17179 for <[e-mail]>; Sun, 8 Oct 2000 20:10:56 -0700 (PDT)
From: [e-mail]
Received: from www.goldendeckcasino.com (adsl-61-143-206.mia.bellsouth.net [208.61.143.206]) by mail1.mia.bellsouth.net (3.3.5alt/0.75.2) with SMTP id XAA28957; Sun, 8 Oct 2000 23:14:04 -0400 (EDT)
Message-Id: <[e-mail]>
To: <>
Subject: WOW!!! Highest Payouts Around!!!!!!!!
Date: Sun, 08 Oct 2000 22:56:15 -0400
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3
X-MSMail-Priority: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Its just like being there. Go to www.goldendeckcasino.com/goldendeckcasino/links/2769.html.

If you would like to be removed from these mailings in the future please mailto:[e-mail]?subject=remove


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA12743 for ietf-smime-bks; Sun, 8 Oct 2000 18:03:36 -0700 (PDT)
Received: from www.sinet.net.cn (szptt103-190.szptt.net.cn [202.103.190.3] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA12738 for <[e-mail]>; Sun, 8 Oct 2000 18:03:34 -0700 (PDT)
From: [e-mail]
Received: from pavilion ([204.32.5.98]) by www.sinet.net.cn (8.8.8+Sun/8.8.8) with SMTP id BAA17566; Mon, 9 Oct 2000 01:03:37 GMT
Date: Mon, 9 Oct 2000 01:03:37 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: At last, HERBAL V the all natural alternative!
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Herbal V: An Incredible All-Natural Healthy Alternative 


  Herbal V is the All Natural Approach to Male Virility,
  Vitality and Pleasure.



Available N o w ! 


Welcome to the New Sexual Revolution.

It's the all natural male potency and pleasure pill that men 
everywhere are buzzing about. Herbal V is safe, natural and
specifically formulated to help support male sexual function
and pleasure. You just take two easy-to-swallow tablets
one hour before sex. And there's more great news - you can
get Herbal V for less than $1 a pill.

Amazing word of mouth praise on Herbal V has been spreading 
like wildfire-already over 1,500,000 men  have chosen
Herbal V. Since it is 100% natural you will never have
to worry about safety. Try doctor-recommended Herbal V
today and have the greatest night of your life!


Herbal V... Bringing Back the Magic!


1,585,000 men can't be wrong. To date over 1 million men 
have tried the super supplement Herbal V.
Here is why: 

No Doctor Visit Required 
Available Over the Counter 
Not a Drug 
100% Natural 
Safe, No Worries 
Highest Quality Pharmaceutical-Grade Pure Nutriceuticals 
Guaranteed Potency & Purity 

Be a Real Man Again!

Questions and Answers

What is Herbal V?

Herbal V is a proprietary blend that was specifically
developed as a safe alternative for men who prefer
an all-natural approach to address impotence and boost
sexual performance. This amazing formula first became
popular with Hollywood insiders and the wealthy elite.
They were maximizing their sex lives, long before it 
was available to the general public. 

How does Herbal V work?

Developed by a team whose goal was to create the perfect 
all-natural aphrodisiac. Herbal V is the result of that
remarkable effort. The Herbal V formula contains a precise
blend of cutting edge pro-sexual nutrients from around
the world that provide nutritional support, making it
possible for a man to have a pleasurable sexual experience. 

What can Herbal V do for me?

Herbal V helps support male sexual function and 
pleasure in a safe and natural manner. Simply put, 
it can make your sex life incredible. 

Is Herbal V Safe?

One of the great things about Herbal V is that it is
not a drug. It is an incredible herbal dietary supplement
that provides nutritional support for male sexual function
and pleasure. One of the most comforting features of
Herbal V is that you never have to worry about safety. 

Herbal V: Safe - Natural - Exciting

Many have speculated that because Herbal V is so
popular with men, it must contain prescription drugs
or chemical components. Herbal V does not contain any 
elements or traces of any prescription drug. Herbal V 
is made using the world's most technologically advanced
state-of-the-art cold processing equipment to ensure
maximum purity. Herbal V has been independently analyzed
by the nation's premier testing facility to ensure purity,
quality and to end the rumors that, because it is so
popular, it must somehow be chemical. It is not.
Herbal V is natural - just as it says on the label.
Herbal V is simply fantastic! 

Herbal V: Ingredients

Yohimbe, saw palmetto, avena sativa, androstenedione,
guarana, taurine, siberian ginseng, tribulus terrestris. 
Tribulus Terrestis is certified to enhanced testosterone
levels by increasing Luteinzing hormone (LH) levels. 
Androstenedione which is a precursor to testosterone
unlocks bound testosterone and makes it biologically
active again quickly. This means a dramatic surge in 
desire. Avena Sativa Stimulates the neurotransmitter 
pleasure centers to maximum capacity. This greatly
intensifies pleasure.

Just listen to what Herbal V has done for the sex lives
of people like you!

“On a scale of 1 to 10, it's a 15. Electrifying. It's like 
a wonder pill!” 
— Justin Q B., New Haven, Texas

“I haven't had sexual relations in 11 years. Then with 
Herbal V it was... wow! It works again!” 
— Sid R., Lakeland, Florida

“I had sex four times in one night. It made me feel
like a 19-year-old again.” 
— Chip S, Beech Mountain, North Carolina

“Herbal V has turned my husband into a Sexual Superman! 
I like the fact that it's all natural and has no
side effects. It's bringing back the good old days.” 
— Jennifer B, Beverly Hills, California 

The above testimonials are from product literature, 
and we have not independently verified them.
However, the following testimonial is from a "senior"
gentleman who has purchased his second bottle of
Herbal V. When we heard his words with our own ears,
we asked his permission to print them here. 

 “Man! I'm wild as I can be! I feel like I'm 25 years old again! 
I'm not believing this!” 
                          — Mr. Murphy, age 64, Lampart, IL.



Risk Free: Double Your Money Back Guarantee

If Herbal V does not give the desired results as stated
above, simply return the unused portion for a
double-your money back refund. No questions asked ! 

Order Now: Safe, Fast, Secure, Private

Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is
available only through this special promotional offer.
Herbal V arrives in plain packaging for your privacy.
Any and all information is kept strictly confidential.

Payment Methods

You may FAX or Postal Mail Checks, MasterCard, Visa,
& American Express.payments. Money Orders
are accepted only by Postal Mail. 


Each bottle of Herbal V contains 30 tablets, approximately
a 1 month supply.


Step 1: Place a check by your desired quanity.


______ 1 Bottle of Herbal V  $24


______ 2 Bottles of Herbal V $44


______ 3 Bottles of Herbal V $59


Please add $6 shipping and handling for any size order. 
[ Total cost including shipping & handling, 
1 bottle=$30, 2 bottles=$50, 3 bottles=$65 ]

International Orders
Please add $16 shipping and handling for any size order.
[ Total cost including shipping & handling,
1 bottle=$40, 2 bottles=$60, 3 bottles=$75 ]

Step 2: Place a check by your desired payment method 
and complete fields if necessary.


_____Check or CHECK-BY-FAX [details below]


_____Money Order 


_____American Express 
Account Number__________________ Exp____/____

_____Visa
Account Number__________________ Exp____/____

_____MasterCard
Account Number__________________ Exp____/____


Please make your check or money order payable to
"Lion Sciences National".
 

Step 3: Please complete and print the following fields clearly.


Name ___________________________________________________ 


Address _________________________________________________


City ____________________________________________________ 


State ___________________________________________________ 


Zip _____________________________________________________ 


E-mail __________________________________________________ 


Signature _________________________________________________
[ required for check and credit card orders]



             Toll Free FAX Order Line: 1-800-940-6590
If faxing in your order, please state whether you require
a fax, email, or no confirmation at all. 
Allow up to one day for confirmation, if requested.
FAX orders are processed immediately.

  Or, print & mail to: LSN   
                       3502 N. Powerline Rd. #525 
                       Pompano Beach, FL 33069                


        ______________________________________________________


*CHECK BY FAX ORDERS: Complete the check as normal. Tape
the check in the area below. Below the check, clearly write
the check number, all numbers at the bottom of the check,
& your name. Tape the check below and fax the check to the
toll free FAX number above. Void the check. Our merchant
will electronically debit your account for the amount of 
the check; your reference number for this transaction will
be your check number. Nothing could be safer & easier !

                          TAPE CHECK BELOW















              _____________________________________________________________

This is a one time mailing: Removal is automatic and no further 
contact is necessary. Please Note: Herbal V is not intended to
diagnose, treat, cure or prevent any disease. As individuals differ,
so will results. Herbal V helps provide herbal and nutritional support
for male sexual performance. The FDA has not evaluated these 
statements. For details about our double your money back guarantee,
please write to the above address, attention consumer affairs 
department; enclose a self addressed stamped envelope for this and any 
requested contact information.
Thank You.


Received: by ns.secondary.com (8.9.3/8.9.3) id MAA09141 for ietf-smime-bks; Thu, 5 Oct 2000 12:22:31 -0700 (PDT)
Received: from aeposmail.aepos.com (aeposmail.aepos.com [209.112.11.5]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA09137 for <[e-mail]>; Thu, 5 Oct 2000 12:22:29 -0700 (PDT)
From: [e-mail]
Received: by aeposmail.aepos.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 8525696F.0065CD10 ; Thu, 5 Oct 2000 14:31:56 -0400
X-Lotus-FromDomain: AEPOS
To: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 5 Oct 2000 13:53:33 -0400
Subject: RE: ESS Questions
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>4.2.3.2 Processing for SignedData
>
>Q.  Step 2 of this process has been changed from the
>Internet draft version (draft-ietf-smime-ess-09.txt).  It
>seems that now if the "outer" signed data layer is absent
>or does not contain an mlExpansionHistory attribute, the
>MLA simply adds a new outer signed layer, lists itself in
>the mlExpansionHistory attribute, and sends the message to
>the recipients.  It would no longer expand any encrypted
>data for the recipients.  If someone sent a message that
>was encrypted then signed to the MLA, the recipients would
>not be able to decrypt it.  Have I misread this paragraph?
>
>[JSP: You have misinterpreted the paragraph.]

Did I also misinterpret the flowchart (quoted below)?

   1. Has a valid signature?
          YES -> 2.
          NO  -> STOP.
   2. Does outermost SignedData layer contain mlExpansionHistory?
          YES -> Check it, then -> 3.
          NO  -> Sign message (including outermost SignedData that
                 doesn't have mlExpansionHistory), deliver it, STOP.

   It seems clear that the MLA would not expand encrypted data unless the outer
signature is either absent or that of an MLA.




Received: by ns.secondary.com (8.9.3/8.9.3) id DAA11760 for ietf-smime-bks; Tue, 3 Oct 2000 03:45:58 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA11755 for <[e-mail]>; Tue, 3 Oct 2000 03:45:56 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05449; Tue, 3 Oct 2000 06:49:48 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-seclabel-02.txt
Date: Tue, 03 Oct 2000 06:49:48 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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		: Implementing Company Classification Policy with the 
                          S/MIME Security Label
	Author(s)	: W. Nicolls
	Filename	: draft-ietf-smime-seclabel-02.txt
	Pages		: 10
	Date		: 02-Oct-00
	
This document discusses how company security policy for data classification can be mapped to the S/MIME security label.  Actual policies from 3 companies are used to provide worked examples.  
Security labels are an optional security service for S/MIME. A security label is a set of security information regarding the sensitivity of the content that is protected by S/MIME encapsulation. A security label can be included in the signed attributes of any SignedData object.  A security label attribute may be included in either the inner signature, outer signature, or both.
The syntax and processing rules for security labels are described in [ESS].

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

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-seclabel-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-seclabel-02.txt

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA28160 for ietf-smime-bks; Mon, 2 Oct 2000 16:30:14 -0700 (PDT)
Received: from eps1.eps.telstra.com.au (payment.eps.telstra.com.au [192.148.148.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA28155 for <[e-mail]>; Mon, 2 Oct 2000 16:30:12 -0700 (PDT)
Received: from host (sdn-ar-001riprovP303.dialsprint.net [168.191.126.169]) by eps1.eps.telstra.com.au (8.8.8+Sun/8.8.5) with ESMTP id JAA22950; Tue, 3 Oct 2000 09:20:56 +1000 (EST)
Message-Id: <[e-mail]>
From: "Dennis Peters" <[e-mail]>
Subject: Real Estate and Business Owners #6AA3
To: [e-mail]
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3
Mime-Version: 1.0
Date: Mon, 02 Oct 2000 18:50:51 -0500
Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a MIME Message

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

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

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


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

<html>

<head>

<body bgcolor=3D"#3366FF">

<h2 align=3D"center"><font color=3D"#FFFFFF">SKY DEVELOPMENT SOLUTIONS</fo=
nt></h2>
<h3 align=3D"center">We provide the perfect solutions=2E</h3>
<p align=3D"left">&nbsp;</p>
<p align=3D"left"><font color=3D"#FFFFFF"><b>We have investor's that would=
 like to
Buy Real Estate with creative Financing or No money down in USA or Canada=2E=
&nbsp;
Our buyer network is looking for commercial Real Estate from</b></font><em=
><br>
</em><font face=3D"Arial Black" size=3D"3"><em>1 million to 100 million</e=
m></font></p>
<ul>
  <li>
    <p align=3D"left"><font face=3D"Arial Black" color=3D"#FFFFFF">Apartme=
nt Complex </font></li>
  <li>
    <p align=3D"left"><font face=3D"Arial Black" color=3D"#FFFFFF">Office =
Building </font></li>
  <li>
    <p align=3D"left"><font face=3D"Arial Black" color=3D"#FFFFFF">Mobile =
Home </font></li>
  <li>
    <p align=3D"left"><font face=3D"Arial Black" color=3D"#FFFFFF">Park Sh=
opping
    Centers </font></li>
  <li>
    <p align=3D"left"><font face=3D"Arial Black" color=3D"#FFFFFF">Industr=
ial Park </font></li>
  <li>
    <p align=3D"left"><font face=3D"Arial Black" color=3D"#FFFFFF">Hotel a=
nd Motel's</font></li>
</ul>
<p align=3D"center">&nbsp;</p>
<p align=3D"center"><font color=3D"#FFFFFF"><u>MOBILE HOME PARKS</u></font=
></p>
<div align=3D"center">
  <font face=3D"Arial, helvetica"><font color=3D"#FFFFFF">$250,000 and up!=
</font>
  </div>
  <div align=3D"center">
    <font color=3D"#FFFFFF">Refinance</font>
  </div>
  <div align=3D"center">
    <font color=3D"#FFFFFF">purchase</font>
  </div>
  <div align=3D"center">
    <font color=3D"#FFFFFF">construction</font>
  </div>
  <div align=3D"center">
    &nbsp;
  </div>
  <div align=3D"center">
    &nbsp;
  </div>
  <div align=3D"center">
    <strong><font color=3D"#FFFFFF">Did your banker laugh at you when you =
asked
    for a loan?</font></strong>
    <p><font color=3D"#FFFFFF">With our venture capital lending programs w=
e fill
    needs of borrowers who are unable to find conventional financing=2E&nb=
sp; For
    your business startup or your business expansion we can offer you over=
 250
    venture capital lenders from $100,000 to $1,000,000 and up=2E&nbsp; (T=
hese
    programs are only for U=2ES Residents)=2E</font></p>
    <p>&nbsp;
  </div>
</font>
<hr>
<p align=3D"center"><b><font color=3D"#FFFFFF">FREE INFORMATION PACK FOR S=
ERIOUS
INQUIRIES </font></b></p>
<form name=3D"form"
  method=3D"post"
  action=3D"mailto:gm99t@cmpmail=2Ecom?SUBJECT=3DInternet Lead"
  enctype=3D"text/plain"
  onSubmit=3D"return validate_form()"></caption>
 
 <tr>
  <p align=3D"left"><input type=3D"text" name=3D"Name" size=3D"20"> Name</=
p>
  <p align=3D"left"><input type=3D"text" name=3D"Address" size=3D"20"> Add=
ress</p>
  <p align=3D"left"><input type=3D"text" name=3D"Citystate" size=3D"20"> C=
ity, State,
  Zip</p>
  <p align=3D"left"><input type=3D"text" name=3D"Phone" size=3D"20"> Phone=
</p>
  <p align=3D"left"><input type=3D"text" name=3D"Fax" size=3D"20"> Fax </p=
>
  <p align=3D"left"><input type=3D"text" name=3D"email" size=3D"20"> E-mai=
l</p>
  <p align=3D"left">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <input type=3D"submit" =
value=3D"GET INFO!" name=3D"B1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  </p>
</form>
<p align=3D"left">&nbsp;</p>


<hr WIDTH=3D"100%">
 <br><b><font color=3D"#66cc99"><font size=3D+1>List
 Removal/OPT-OUT Option</font></font></b>
 <br><b><font color=3D"#000000"><font size=3D-1><a
 href=3D"mailto:derr9@goplay=2Ecom?subject=3Dremove">Click
 Here</a></font></font></b></center>

</BODY>
</HTML>


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

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