Document Action: Electronic Signature Formats for long term electronic signatures to Informational

[The IESG <[e-mail]>]

The IESG has approved the Internet-Draft 'Electronic Signature Formats for long
term electronic signatures' <draft-ietf-smime-esformats-03.txt> as an Informational 
RFC. This document is the product of the S/MIME Mail Security Working Group.
The IESG contact persons are Jeffrey Schiller and Marcus Leech.



Received: by above.proper.com (8.9.3/8.9.3) id IAA27699 for ietf-smime-bks; Mon, 30 Apr 2001 08:58:07 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA27694 for <[e-mail]>; Mon, 30 Apr 2001 08:58:05 -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 LAA16659; Mon, 30 Apr 2001 11:58:00 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>
Cc: [e-mail]
From: The IESG <[e-mail]>
Subject: Document Action: Electronic Signature Policies to Experimental
Date: Mon, 30 Apr 2001 11:58:00 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the Internet-Draft 'Electronic Signature Policies'
<draft-ietf-smime-espolicies-00.txt> as an Experimental Protocol.
This document is the product of the S/MIME Mail Security Working Group.
The IESG contact persons are Jeffrey Schiller and Marcus Leech.


Received: by above.proper.com (8.9.3/8.9.3) id IAA27540 for ietf-smime-bks; Mon, 30 Apr 2001 08:56:47 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA27535 for <[e-mail]>; Mon, 30 Apr 2001 08:56:45 -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 LAA16571; Mon, 30 Apr 2001 11:56:35 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>, IANA <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>
Cc: [e-mail]
From: The IESG <[e-mail]>
Subject: Document Action: Electronic Signature Formats for long term electronic signatures to Informational
Date: Mon, 30 Apr 2001 11:56:35 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the Internet-Draft 'Electronic Signature Formats for long
term electronic signatures' <draft-ietf-smime-esformats-03.txt> as an Informational 
RFC. This document is the product of the S/MIME Mail Security Working Group.
The IESG contact persons are Jeffrey Schiller and Marcus Leech.


Received: by above.proper.com (8.9.3/8.9.3) id GAA25843 for ietf-smime-bks; Sat, 28 Apr 2001 06:25:59 -0700 (PDT)
Received: from mail2.okwork.gov.tw (IDENT:root@[163.29.128.16]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA25834 for <[e-mail]>; Sat, 28 Apr 2001 06:25:57 -0700 (PDT)
From: [e-mail]
Received: from 44mexi7server42 (IDENT:[e-mail] [127.0.0.1]) by mail2.okwork.gov.tw (8.9.3/8.9.3) with SMTP id VAA06138 for [e-mail]; Sat, 28 Apr 2001 21:34:47 +0800
Date: Sat, 28 Apr 2001 21:34:47 +0800
Message-Id: <[e-mail]>
To: <[e-mail]>
Subject: ADV: Top Search Engine Placement
MIME-Version: 1.0
Content-Type: text/plain; charset=unknown-8bit
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>

Removal instructions below.

I saw your listing on the internet.

I work for a company that specializes
in getting clients web sites listed
as close to the top of the major 
search engines as possible.

Our fee is only $29.95 per month to
submit your site at least twice a
month to over 350 search engines 
and directories.

To get started and put your web site
in the fast lane, call our toll free
number below.


Mike Bender
888-532-8842


To be removed call: 888-800-6339 X1377




Received: by above.proper.com (8.9.3/8.9.3) id FAA16766 for ietf-smime-bks; Fri, 27 Apr 2001 05:17:15 -0700 (PDT)
Received: from lancaster.nexor.co.uk (lancaster.nexor.co.uk [193.63.53.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA16762 for <[e-mail]>; Fri, 27 Apr 2001 05:17:14 -0700 (PDT)
Received: from dell32022k (actually host dell3202-2k.nexor.co.uk) by lancaster.nexor.co.uk with SMTP (Mailer); Fri, 27 Apr 2001 13:17:09 +0100
Reply-To: "w.adams" <[e-mail]>
From: William Adams <[e-mail]>
To: ietf-smime <[e-mail]>
Subject: SMIME Version?
Date: Fri, 27 Apr 2001 13:16:58 +0100
Message-ID: <000201c0cf13$f562b930$8b353fc1@dell32022k>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

If I have an SMIME message how can I tell what version it is? (i.e. S/MIMEv2
or v3)

William Adams
Software Engineer
Nexor.
================
Tel:  [phone]
Fax: [phone]



Received: by above.proper.com (8.9.3/8.9.3) id FAA15907 for ietf-smime-bks; Fri, 27 Apr 2001 05:07:01 -0700 (PDT)
Received: from lancaster.nexor.co.uk (lancaster.nexor.co.uk [193.63.53.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA15902 for <[e-mail]>; Fri, 27 Apr 2001 05:07:00 -0700 (PDT)
Received: from dell32022k (actually host dell3202-2k.nexor.co.uk) by lancaster.nexor.co.uk with SMTP (Mailer); Fri, 27 Apr 2001 13:06:55 +0100
Reply-To: "w.adams" <[e-mail]>
From: William Adams <[e-mail]>
To: ietf-smime <[e-mail]>
Subject: SMIME Version?
Date: Fri, 27 Apr 2001 13:06:43 +0100
Message-ID: <000001c0cf12$87401a20$8b353fc1@dell32022k>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

If I have an SMIME message how can I tell what version it is? (i.e. S/MIMEv2
or v3)

William Adams
Software Engineer
Nexor.
================
Tel:  [phone]
Fax: [phone]



Received: by above.proper.com (8.9.3/8.9.3) id NAA10912 for ietf-smime-bks; Thu, 26 Apr 2001 13:22:03 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id NAA10903 for <[e-mail]>; Thu, 26 Apr 2001 13:22:00 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 26 Apr 2001 20:21:58 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA08856 for <[e-mail]>; Thu, 26 Apr 2001 16:22:00 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id <JST3WNVR>; Thu, 26 Apr 2001 16:22:00 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.45]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JST3WNVP; Thu, 26 Apr 2001 16:21:55 -0400
From: "Housley, Russ" <[e-mail]>
To: Simon Blake-Wilson <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 26 Apr 2001 16:21:50 -0400
Subject: RE: S/MIME ECC Doc
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon:

> > Please add a Intellectual Property Rights section to the document.  Please
> > take a look a section 9 of RFC 2459 for an example.  Also, take a look at
> > the references made in the discussion of the RSA algorithm (the patent had
> > not expired when RFC 2459 was published).  This provides a simple 
> "heads up."
>
>I think we already have an IPR section in the document. Rather than single out
>one algorithm for an IPR pointer, we propose to add a sentence to the abstract
>along the similar lines to 2459 - something like "An IPR statement 
>regarding the
>use of ECC in CMS can be found in Section xyz". Okay?

  Fine.

Russ


Received: by above.proper.com (8.9.3/8.9.3) id EAA01283 for ietf-smime-bks; Thu, 26 Apr 2001 04:22:14 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA01273 for <[e-mail]>; Thu, 26 Apr 2001 04:22:12 -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 HAA28261; Thu, 26 Apr 2001 07:22:11 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-cmsalg-00.txt
Date: Thu, 26 Apr 2001 07:22:10 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Cryptographic Message Syntax (CMS) Algorithms
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cmsalg-00.txt
	Pages		: 22
	Date		: 25-Apr-01
	
This document describes cryptographic algorithms for use with the
Cryptographic Message Syntax (CMS) [CMS].  CMS is used to digitally
sign, digest, authenticate, or encrypt arbitrary messages.
Once approved, this draft will obsolete section 12 of RFC 2630.  The
companion document (draft-ietf-smime-rfc2630bis-00.txt) will obsolete
the rest of RFC 2630.  Separation of the protocol and algorithm
specifications allows the IETF to select different mandatory to
implement algorithms in the future without reissuing the protocol
document.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-cmsalg-00.txt".

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cmsalg-00.txt

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.9.3/8.9.3) id EAA01264 for ietf-smime-bks; Thu, 26 Apr 2001 04:22:09 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA01255 for <[e-mail]>; Thu, 26 Apr 2001 04:22:07 -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 HAA28244; Thu, 26 Apr 2001 07:22:06 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-rfc2630bis-00.txt
Date: Thu, 26 Apr 2001 07:22:06 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Cryptographic Message Syntax
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-rfc2630bis-00.txt
	Pages		: 49
	Date		: 25-Apr-01
	
This document describes the Cryptographic Message Syntax (CMS).  This
syntax is used to digitally sign, digest, authenticate, or encrypt
arbitrary messages.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-rfc2630bis-00.txt".

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-rfc2630bis-00.txt

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.9.3/8.9.3) id KAA08915 for ietf-smime-bks; Wed, 25 Apr 2001 10:04:58 -0700 (PDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.9.3/8.9.3) with SMTP id KAA08910 for <[e-mail]>; Wed, 25 Apr 2001 10:04:57 -0700 (PDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id LAA13925; Wed, 25 Apr 2001 11:56:19 -0400
Received: from rftzy232.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 25 Apr 2001 11:56:01 -0400
Received: from NORTELNETWORKS.COM (wftzh00e.ca.nortel.com [47.130.116.9])  by rftzy232.ca.nortel.com  with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)  id JHXCM4T8; Wed, 25 Apr 2001 11:52:37 -0400
Message-ID: <[e-mail]>
Date: Wed, 25 Apr 2001 11:56:10 -0400
From: "Marcus Leech" <[e-mail]>
X-Mailer: Mozilla 4.73C-CCK-MCD [en] (X11; U; HP-UX B.10.20 9000/785)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: draft-ietf-smime-password-03.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Orig: <[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>

Enough issues were raised with this document during last call that I'm returning
  it to the WG for a re-fit.  The document author is in possession of the
  LAST CALL comments.

-- 
----------------------------------------------------------------------
Marcus Leech                             Mail:   Dept 8M70, MS 012, FITZ
Advisor                                  Phone: (ESN) 393-9145  [phone]
Security Architecture and Planning       Fax:   (ESN) 393-9435  [phone]
Nortel Networks                          [e-mail]
-----------------Expressed opinions are my own, not my employer's------


Received: by above.proper.com (8.9.3/8.9.3) id EAA21870 for ietf-smime-bks; Wed, 25 Apr 2001 04:41:26 -0700 (PDT)
Received: from mail.ca.certicom.com (ip6.certicom.com [209.121.99.6] (may be forged)) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA21866 for <[e-mail]>; Wed, 25 Apr 2001 04:41:25 -0700 (PDT)
Received: from smtpmail.certicom.com (domino2.certicom.com [10.0.1.25]) by mail.ca.certicom.com (8.9.3/8.9.3) with SMTP id HAA05048 for <[e-mail]>; Wed, 25 Apr 2001 07:34:56 -0400 (EDT)
Received: by smtpmail.certicom.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256A39.004017B5 ; Wed, 25 Apr 2001 07:40:03 -0400
X-Lotus-FromDomain: CERTICOM
From: "Simon Blake-Wilson" <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 24 Apr 2001 17:48:16 -0400
Subject: RE: S/MIME ECC Doc
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Russ,

Thanks for the speedy response.

> I have no problem with this.  Can we add a paragraph to the Security
> Considerations that warns implementors that a wider has MAY be specified
> when stronger (symmetric algorithms with longer key sizes) are supported
> (e.g., AES)?

Okay.

> Please add a Intellectual Property Rights section to the document.  Please
> take a look a section 9 of RFC 2459 for an example.  Also, take a look at
> the references made in the discussion of the RSA algorithm (the patent had
> not expired when RFC 2459 was published).  This provides a simple "heads up."

I think we already have an IPR section in the document. Rather than single out
one algorithm for an IPR pointer, we propose to add a sentence to the abstract
along the similar lines to 2459 - something like "An IPR statement regarding the
use of ECC in CMS can be found in Section xyz". Okay?

Best regards. Simon





Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA21670 for ietf-smime-bks; Tue, 24 Apr 2001 14:16:25 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id OAA21659 for <[e-mail]>; Tue, 24 Apr 2001 14:16:19 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 24 Apr 2001 21:16:19 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA07749 for <[e-mail]>; Tue, 24 Apr 2001 17:16:20 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id <JST3V3P5>; Tue, 24 Apr 2001 17:16:20 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.3]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JST3V3PV; Tue, 24 Apr 2001 17:16:12 -0400
From: "Housley, Russ" <[e-mail]>
To: Simon Blake-Wilson <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 24 Apr 2001 16:06:06 -0400
Subject: RE: S/MIME ECC Doc
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon:

>(1) The specification only employs SHA-1. Should it be extended to include
>to SHA-256 in anticipation of 128-bit AES keys?
>
>Our goal was not to specify "new crypto" in this spec but rather leave that up
>to the groups that focus on writing crypto specs. I don't know of any crypto
>specs that have added SHA-2 support yet. So I'd propose to specify use of 
>SHA-1
>until the crypto specs add SHA-2 ... at which point we can add SHA-2 
>support in
>a new draft or a rev of this spec.

I have no problem with this.  Can we add a paragraph to the Security 
Considerations that warns implementors that a wider has MAY be specified 
when stronger (symmetric algorithms with longer key sizes) are supported 
(e.g., AES)?

>(2) Does the 1-pass D-H scheme use co-factor multiplication? I understand
>that it is possible to do it done with or without co-factor multiplication,
>so I am really seeking clarification here.  Are there IPR issues regarding
>the choice?
>
>All we do is reference X9.63 which allows either "regular" ECDH or "cofactor"
>ECDH ... so yes the 1-pass ECDH scheme allows cofactor ECDH. There are IPR
>issues with cofactor ECDH (as with other EC schemes) ... here's what I know
>about Certicom's IPR in this area (usual disclaimers, etc, etc):
>
>- Certicom's SMIME IPR statement ...
>http://www.ietf.org/ietf/IPR/CERTICOM-SMIME-1
>- Certicom's IEEE 1363 statement ...
>http://grouper.ieee.org/groups/1363/P1363/patents.html
>- As far as I know, the most relevant patent is 5,933,504.

Please add a Intellectual Property Rights section to the document.  Please 
take a look a section 9 of RFC 2459 for an example.  Also, take a look at 
the references made in the discussion of the RSA algorithm (the patent had 
not expired when RFC 2459 was published).  This provides a simple "heads up."

>(3) Can you say something about the unknown key-share attack on MQV?  I
>understand that this vulnerability can be avoided by explicit key
>authentication.  A paragraph in the Security Considerations section should
>be sufficient.
>
>Sure we'll add a paragraph to Security considerations. Briefly, unknown
>key-share is about fooling Bob into thinking a CEK he actually shares with 
>Alice
>is in fact shared with Eve. If Eve can do this, then maybe she can fool 
>Bob into
>believing a message from Alice is in fact from Eve. Unknown key-share is
>therefore mainly concerned with authenticated and encrypted data ... 
>because for
>example, Eve can always take a message that she sees Alice sign and send 
>to Bob,
>and replace it with the same message, signed with Eve's key. When 1-pass 
>MQV is
>used in CMS to authenticate then encrypt data, the unknown key-share issue 
>with
>MQV doesn't arise because the ephemeral public key of Alice is included inside
>authenticated-data, and therefore inside the encrypted content.

Thanks.  I look forward to the updated security considerations.

>(4) Section 3.2.2. "Parity bits adjusted according to the keywrap
>algorithm" is rather vague.  Please extract the appropriate text from RFC 
>2630.
>
>To be as clear as possible, we propose to replace the quoted text with a 
>simple
>reference to 2630.

Fine.  Please reference a particular section in RFC 2630.

Russ


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA18875 for ietf-smime-bks; Tue, 24 Apr 2001 13:52:38 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA18869; Tue, 24 Apr 2001 13:52:36 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <H95F5J4B>; Tue, 24 Apr 2001 16:52:19 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "Pawling, John" <[e-mail]>
Subject: v1.10 S/MIME Freeware Library Now Available
Date: Tue, 24 Apr 2001 16:52:06 -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 has delivered Version 1.10 of the 
S/MIME Freeware Library (SFL) source code.  The SFL source code files 
are freely available to everyone from the Getronics Government 
Solutions web site at <http://www.getronicsgov.com/hot/sfl_home.htm>.    

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++ v4.1 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/98/2000, 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++ v4.1 library; RSA suite of algorithms
provided 
by the RSA BSAFE v4.2 and Crypto++ v4.1 libraries; and Fortezza suite of 
algorithms provided by the Fortezza Crypto Card.  The v1.10 SFL uses the
v1.3 R6 
Enhanced SNACC ASN.1 Library to encode/decode objects. The v1.10 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; v1.3
R6
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, 
Netscape Communicator 4.X and Entrust S/MIME v2 products.  Signed messages 
have been exchanged with the RSA S/MAIL and WorldTalk 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 also used the SFL to generate S/MIME v3 sample 
messages that were included in the "Examples" document.
We have also performed limited S/MIME v3 testing with Baltimore.  

The following enhancements are included in the v1.10 SFL and CTIL releases
(compared with the v1.9 releases):

1) Tested using common v1.3 R6 Enhanced SNACC ASN.1 Library, v1.10 CTILs 
and LIBCERT libraries shared with the v1.5 Access Control Library (ACL) 
and v1.9.1 Certificate Management Library (CML).

2) Corrected the SFL to use the id-dsa-with-sha1 object identifier for
Digital Signature Algorithm (DSA) signatures as specified in RFC 2630.

3) Corrected the SFL to properly implement the following requirement as
specified in RFC 2630, Section 12.3.1: "For key agreement of RC2 
key-encryption keys, 128 bits must be generated as input to the key 
expansion process used to compute the RC2 effective key [RC2]."  

4) Fixed bugs in CertificateBuilder test utility use of Crypto++ 4.1
to generate keys.

5) Added DSA and Secure Hash Algorithm (SHA)-256 code to Common
CTIL Class.

6) Enhanced "common CTIL" Class so that it is truly common to all 
CTILs (provides SHA-1, SHA-256, DSA and Advanced Encryption
Standard (AES)).  Modified LibCert to use "common CTIL" capability.

7) Fixes bugs in SPEX/ CTIL and Free3 CTIL.

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

The use of the v1.10 SFL is described in the v1.9 SFL Application 
Programming Interface (API) and v1.9 SDD API documents.  The v1.0 SMP 
Components Setup Manual that describes the component installation
procedures for the v1.10 SFL, v1.9.1 CML, and v1.3 R6 Enhanced SNACC
libraries.

We are still in the process of enhancing and testing the SFL.  Future 
releases will include: additional PKCS #11 CTIL testing; finish 
CertificateBuilder command line utility; enhancing 
CertificateBuilder to support creation of Attribute Certificates; 
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 <http://www.GetronicsGov.com/>:

1) SFL Documents: Fact Sheet, Software Design Description, API, CTIL 
API, Software Test Description, Implementers Guide, Overview Briefing and 
Public License.     

2) smimeR1.10.tar.gz:  Source code, MS Windows NT/95/98/2000 project files
and 
Unix makefiles for SFL Hi-Level library.

3) snacc13r6rn.tar.gz (source code and binaries available from Getronics 
Enhanced SNACC web page: <http://www.getronicsgov.com/hot/snacc_home.htm>): 
Source code, MS Windows NT/95/98/2000 project files and Unix makefiles for
v1.3 R6 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.10.tar.gz:  Source code, MS Windows NT/98/2000 project files and 
Unix makefiles for the following CTILs: Test (no crypto), Crypto++, BSAFE, 
Fortezza, SPEX/ and PKCS #11.  The CTIL source code includes PKCS #12 
software developed by the OpenSSL Project for use in the OpenSSL Toolkit
<http://www.openssl.org/>

5) smLibCR1.10.tar.gz: Source code, MS Windows NT/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.10.tar.gz: Source code, MS Windows NT/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.  Getronics 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".

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 National Institute of Standards and Technology (NIST) is providing 
test S/MIME messages (created by Getronics) at 
<http://csrc.nist.gov/pki/testing/x509paths.html>.  
Getronics used the SFL to successfully process the NIST test data.

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: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA17728 for ietf-smime-bks; Tue, 24 Apr 2001 08:06:10 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA17718 for <[e-mail]>; Tue, 24 Apr 2001 08:06:08 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id LAA16760 for <[e-mail]>; Tue, 24 Apr 2001 11:05:40 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Tue, 24 Apr 2001 11:03:41 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: S/MIME version number and Attribute Certificates
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John,

I stand corrected on RecipientInfo, which contains no certificates,
attribute or otherwise.  I was thinking of CertificateSet, which as
you say is included in SignedData and the OriginatorInfo field of
EnvelopedData.

RFC2630's CertificateChoices contains:
  attrCert [1] IMPLICIT AttributeCertificate,

and unless I misunderstood your proposal, it would have continued to
contain the identical attrCert field with the identical Context 1
tag.  Were you proposing to add a new CHOICE option?, i.e.

  2000attrCert [2] IMPLICIT AttributeCertificate

If so, I believe a new context tag is unnecessary.  If not, then
I believe that the syntax of SignedData, EnvelopedData, and any
other structure which incorporates CertificateSet is not changed,
only the syntax of AttributeCertificate itself is changed.

Russ gets your point that v1 and v2 attribute certificates
are not compatible.  Perhaps I'm dense, but I still don't get
it.  I have two draft X.509 documents which say:

1997:  AttributeCertificateInfo ::= SEQUENCE {
          version Version DEFAULT v1,   -- shall be v1
          subject CHOICE {
            .
            .
       }

2000:  AttributeCertificateInfo ::= SEQUENCE {
          version AttCertVersion DEFAULT v1,    -- can be v1 or v2 - NOT!
          owner   Owner,
             .
             .
       }

I understand that 2000's owner is a SEQUENCE and 1997's subject is
a bare choice.  And perhaps there is still a defect in the latest draft
of 2000 which permits v1 to be used with the SEQUENCE syntax.  But
if v1 is used exclusively for ACs with the 1997 syntax and v2 is used
exclusively for the 2000 syntax, then a decoder can determine
how to interpret the rest of the AC after examining the version field.
ACs are an example of proper incrementing of a version number.  PKCs are
an example of unnecessary incrementing because v2 and v3 follow the
rules of extensibility from v1.

Whether or not X.509 incorrectly permits v1 to be used in 2000-syntax
ACs, a 1997 CMS decoder should be able to detect that it has found
garbage in a CertificateChoice [1] field and proceed to process the
message after ignoring the garbage.  I believe that is a better solution,
regardless of AC deployment history, than incrementing the SignedData
and EnvelopedData versions and forcing 1997 decoders to discard entire
messages.

Regards,
Dave



"Pawling, John" wrote:
> 
> Dave,
> 
> I have some comments regarding statements made in your message:
> 
> 1) You stated: "specific issue of RIs containing V2 ACs".  None of the
> RFC2630 RecipientInfo CHOICE types are capable of containing ACs.
> 
> 2) You stated: "The version number contained within an Attribute Certificate
> is sufficient in principle for a decoder of an outer object (EnvelopedData)
> to determine whether the inner (AC) version is supported,..."  I disagree
> with your use of the terms "outer object" and "inner object".  The AC syntax
> is an integral part of the SignedData and EnvelopedData syntaxes which are
> the "outer objects".  Changing the AC syntax changes the SignedData and
> EnvelopedData (a.k.a. "outer") syntaxes.  I still believe that incrementing
> the version number when v2 ACs are used is the technically correct position
> and is consistent with the use of version numbers in other specs.  For
> example, when the X.509 certificate and AC syntaxes changed, new version
> numbers were defined.  I retracted my comment because it seemed that nobody
> has operationally used 1997 ACs in SignedData and EnvelopedData objects.  If
> that is the case, then implementers can design their code to handle only the
> new 2000 AC syntax (because the 1997 AC syntax was never used).
> 
> 3) You stated: "I don't buy the argument that some tools don't do the right
> thing and that a
> data standard should therefore do the wrong thing (increment
> EnvelopedData)."  I don't believe that anybody made this argument.  I know
> that I did not.
> 
> ===========================================
> John Pawling, [e-mail]
> Getronics Government Solutions, LLC
> ===========================================


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA17404 for ietf-smime-bks; Tue, 24 Apr 2001 08:00:31 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA17398 for <[e-mail]>; Tue, 24 Apr 2001 08:00:29 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <H95F5FV2>; Tue, 24 Apr 2001 11:01:42 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: RE: RecipientInfo Syntax to support passwords-based key managamen t and more
Date: Tue, 24 Apr 2001 11:01:39 -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>

Russ,

I agree with the proposed changes.

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


Received: by above.proper.com (8.9.3/8.9.3) id HAA17239 for ietf-smime-bks; Tue, 24 Apr 2001 07:53:03 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id HAA17235 for <[e-mail]>; Tue, 24 Apr 2001 07:53:01 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 24 Apr 2001 14:53:01 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA04683 for <[e-mail]>; Tue, 24 Apr 2001 10:53:02 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id <HK1A35PJ>; Tue, 24 Apr 2001 10:53:01 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.120]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HK1A35PF; Tue, 24 Apr 2001 10:52:59 -0400
From: "Housley, Russ" <[e-mail]>
To: "Pawling, John" <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 24 Apr 2001 10:52:49 -0400
Subject: RecipientInfo Syntax to support passwords-based key managament and more
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John:

I think that it is time to take this previously closed discussion to the 
whole list.

John has proposed the following.

>RecipientInfo should be changed as follows (or similar):
>
>      RecipientInfo ::= CHOICE {
>       ktri KeyTransRecipientInfo,
>       kari [1] KeyAgreeRecipientInfo,
>       kekri [2] KEKRecipientInfo,
>       other [3] OtherRecipientInfo}      }
>
>       OtherRecipientInfo ::= SEQUENCE {
>         recipientInfoType OBJECT IDENTIFIER,
>         recipientInfoValue [0] EXPLICIT ANY}

At this point, I think it might be unfair to anyone that may have 
implemented password-based key management.  Therefore, I propose that it 
should be included as a possibility in the base CHOICE.  Thus:

     RecipientInfo ::= CHOICE {
       ktri KeyTransRecipientInfo,
       kari [1] KeyAgreeRecipientInfo,
       kekri [2] KEKRecipientInfo,
       pwri [3] PasswordRecipientinfo,
       other [0] OtherRecipientInfo }

       OtherRecipientInfo ::= SEQUENCE {
         oriType OBJECT IDENTIFIER,
         oriValue [0] EXPLICIT ANY DEFINED BY oriType }

Russ


Received: by above.proper.com (8.9.3/8.9.3) id GAA13200 for ietf-smime-bks; Tue, 24 Apr 2001 06:42:13 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA13196 for <[e-mail]>; Tue, 24 Apr 2001 06:42:11 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <H95F51XY>; Tue, 24 Apr 2001 09:43:08 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: S/MIME version number and Attribute Certificates
Date: Tue, 24 Apr 2001 09:43:06 -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>

Dave,

I have some comments regarding statements made in your message:

1) You stated: "specific issue of RIs containing V2 ACs".  None of the
RFC2630 RecipientInfo CHOICE types are capable of containing ACs.     

2) You stated: "The version number contained within an Attribute Certificate
is sufficient in principle for a decoder of an outer object (EnvelopedData)
to determine whether the inner (AC) version is supported,..."  I disagree
with your use of the terms "outer object" and "inner object".  The AC syntax
is an integral part of the SignedData and EnvelopedData syntaxes which are
the "outer objects".  Changing the AC syntax changes the SignedData and
EnvelopedData (a.k.a. "outer") syntaxes.  I still believe that incrementing
the version number when v2 ACs are used is the technically correct position
and is consistent with the use of version numbers in other specs.  For
example, when the X.509 certificate and AC syntaxes changed, new version
numbers were defined.  I retracted my comment because it seemed that nobody
has operationally used 1997 ACs in SignedData and EnvelopedData objects.  If
that is the case, then implementers can design their code to handle only the
new 2000 AC syntax (because the 1997 AC syntax was never used).    

3) You stated: "I don't buy the argument that some tools don't do the right
thing and that a
data standard should therefore do the wrong thing (increment
EnvelopedData)."  I don't believe that anybody made this argument.  I know
that I did not.   

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




Received: by above.proper.com (8.9.3/8.9.3) id PAA01100 for ietf-smime-bks; Mon, 23 Apr 2001 15:07:09 -0700 (PDT)
Received: from mail.ca.certicom.com (ip6.certicom.com [209.121.99.6] (may be forged)) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA01093 for <[e-mail]>; Mon, 23 Apr 2001 15:07:07 -0700 (PDT)
Received: from smtpmail.certicom.com (domino2.certicom.com [10.0.1.25]) by mail.ca.certicom.com (8.9.3/8.9.3) with SMTP id SAA02336 for <[e-mail]>; Mon, 23 Apr 2001 18:00:41 -0400 (EDT)
Received: by smtpmail.certicom.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256A37.00795BCD ; Mon, 23 Apr 2001 18:05:33 -0400
X-Lotus-FromDomain: CERTICOM
From: "Simon Blake-Wilson" <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 23 Apr 2001 18:03:18 -0400
Subject: RE: S/MIME ECC Doc
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Russ,

Thanks for the comments. Responses below ...

(1) The specification only employs SHA-1. Should it be extended to include
to SHA-256 in anticipation of 128-bit AES keys?

Our goal was not to specify "new crypto" in this spec but rather leave that up
to the groups that focus on writing crypto specs. I don't know of any crypto
specs that have added SHA-2 support yet. So I'd propose to specify use of SHA-1
until the crypto specs add SHA-2 ... at which point we can add SHA-2 support in
a new draft or a rev of this spec.

(2) Does the 1-pass D-H scheme use co-factor multiplication? I understand
that it is possible to do it done with or without co-factor multiplication,
so I am really seeking clarification here.  Are there IPR issues regarding
the choice?

All we do is reference X9.63 which allows either "regular" ECDH or "cofactor"
ECDH ... so yes the 1-pass ECDH scheme allows cofactor ECDH. There are IPR
issues with cofactor ECDH (as with other EC schemes) ... here's what I know
about Certicom's IPR in this area (usual disclaimers, etc, etc):

- Certicom's SMIME IPR statement ...
http://www.ietf.org/ietf/IPR/CERTICOM-SMIME-1
- Certicom's IEEE 1363 statement ...
http://grouper.ieee.org/groups/1363/P1363/patents.html
- As far as I know, the most relevant patent is 5,933,504.

(3) Can you say something about the unknown key-share attack on MQV?  I
understand that this vulnerability can be avoided by explicit key
authentication.  A paragraph in the Security Considerations section should
be sufficient.

Sure we'll add a paragraph to Security considerations. Briefly, unknown
key-share is about fooling Bob into thinking a CEK he actually shares with Alice
is in fact shared with Eve. If Eve can do this, then maybe she can fool Bob into
believing a message from Alice is in fact from Eve. Unknown key-share is
therefore mainly concerned with authenticated and encrypted data ... because for
example, Eve can always take a message that she sees Alice sign and send to Bob,
and replace it with the same message, signed with Eve's key. When 1-pass MQV is
used in CMS to authenticate then encrypt data, the unknown key-share issue with
MQV doesn't arise because the ephemeral public key of Alice is included inside
authenticated-data, and therefore inside the encrypted content.

(4) Section 3.2.2. "Parity bits adjusted according to the keywrap
algorithm" is rather vague.  Please extract the appropriate text from RFC 2630.

To be as clear as possible, we propose to replace the quoted text with a simple
reference to 2630.

Please let me know if the proposed resolutions are not okay.

Best regards. Simon

S. Blake-Wilson
Certicom Corp.




Received: by above.proper.com (8.9.3/8.9.3) id MAA16396 for ietf-smime-bks; Mon, 23 Apr 2001 12:00:52 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA16391 for <[e-mail]>; Mon, 23 Apr 2001 12:00:50 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 23 Apr 2001 19:00:51 UT
Received: from exrsa01.rsa.com (exrsa01.rsa.com [10.81.217.7]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA09566 for <[e-mail]>; Mon, 23 Apr 2001 15:00:51 -0400 (EDT)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <JKXMTRZ3>; Mon, 23 Apr 2001 12:03:10 -0700
Received: from HOUSLEY-LAP.rsasecurity.com (10.3.1.85 [10.3.1.85]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HK1A3QH2; Mon, 23 Apr 2001 15:00:39 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 23 Apr 2001 12:33:05 -0400
Subject: Re:  S/MIME version number and Attribute Certificates
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would like to generalize this debate.  Since we are in the process of 
updating RFC 2630 to change the mandatory-to-implement algorithms, perhaps 
we should add some guidance.  When does the version number need to be 
incremented?  Guidance on versioned structures that contain versioned 
structures is also a good idea.

Russ

At 10:07 AM 4/20/2001 +0000, Peter Gutmann wrote:
>"Pawling, John" <[e-mail]> writes:
>
> >I doubt if many implementations check the EnvelopedData version value before
> >attempting to decode the hex data.  A new version number would have assisted
> >with debugging and error reporting, but it is probably not worth the 
> effort to
> >change the specs and implementations to populate the new version value.
>
>My code does (OK, it's not just pedantic, it's truly anal-retentive :-),
>whether this was a good idea or not would have depended on how EnvelopedData
>versions are interpreted.  If the EnvelopedData version was incremented
>whenever a new RecipientInfo was added then it's bad, because adding a single
>vers.n+1 RI to a bunch of vers.n RIs will change the EnvelopedData version 
>even
>though there are vers.n RIs there which could be processed (that is, the code
>could still process the EnvelopedData except that the presence of the vers.n+1
>value for the EnvelopedData would stop it).  OTOH if the EnvelopedData version
>is only incremented when the overall structure of the EnvelopedData is changed
>then it's fine, because it won't try and decode something in a completely
>different format. There are actually quite a variety of possibilities:
>
>- Change it to n+1 if any n+1 RIs are present (yuck)
>- Change it to n+1 only if there are no vers.n RIs present (arguable, but
>   I don't really like it)
>- Leave it as is and use the RI version numbers to figure out whether you can
>   use a particular RI (ie only change it if the EnvelopedData itself changes
>   but not the RI within it)
>
>The third one seems to be the most sensible.
>
>Peter.


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA20691 for ietf-smime-bks; Mon, 23 Apr 2001 07:24:26 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA20686 for <[e-mail]>; Mon, 23 Apr 2001 07:24:24 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA08237 for <[e-mail]>; Mon, 23 Apr 2001 10:23:56 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Mon, 23 Apr 2001 10:21:47 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: S/MIME version number and Attribute Certificates
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Now that the specific issue of RIs containing V2 ACs is settled by
John's proposal withdrawal, there is an opportunity to make a more
general statement in support of Peter's third option below.

The version number contained within an Attribute Certificate is
sufficient in principle for a decoder of an outer object (EnvelopedData)
to determine whether the inner (AC) version is supported, and if
not, ignore the AC, throw an appropriate diagnostic gracefully,
and continue parsing at the end of the unknown inner object.  I don't
buy the argument that some tools don't do the right thing and that a
data standard should therefore do the wrong thing (increment
EnvelopedData).  And I don't understand the argument that versioning
is related to one-pass-ness; a one-pass structure decoder should be
able to skip unknown inner objects just as easily as a tree builder
or something using Russ' try-this-then-try-that scheme.

Incrementing EnvelopedData is wrong because of the collateral damage
-- it forces correct implementations to reject messages that they could
otherwise have processed by ignoring an unknown AC.  And it is wrong
because it sends the message "those ASN.1 people are sooooo stupid
-- let's just rewrite CMS in XML and avoid problems with tools not
being able to handle version numbers".

Can we adopt a general principle that when evolving the standard,
the first priority should be to minimize damage to capable
implementations?  If a conflict arises with specific toolkit
limitations, the answer should be "improve the toolkit".

Dave



Peter Gutmann wrote:
> 
> "Pawling, John" <[e-mail]> writes:
> 
> >I doubt if many implementations check the EnvelopedData version value before
> >attempting to decode the hex data.  A new version number would have assisted
> >with debugging and error reporting, but it is probably not worth the effort to
> >change the specs and implementations to populate the new version value.
> 
> My code does (OK, it's not just pedantic, it's truly anal-retentive :-),
> whether this was a good idea or not would have depended on how EnvelopedData
> versions are interpreted.  If the EnvelopedData version was incremented
> whenever a new RecipientInfo was added then it's bad, because adding a single
> vers.n+1 RI to a bunch of vers.n RIs will change the EnvelopedData version even
> though there are vers.n RIs there which could be processed (that is, the code
> could still process the EnvelopedData except that the presence of the vers.n+1
> value for the EnvelopedData would stop it).  OTOH if the EnvelopedData version
> is only incremented when the overall structure of the EnvelopedData is changed
> then it's fine, because it won't try and decode something in a completely
> different format. There are actually quite a variety of possibilities:
> 
> - Change it to n+1 if any n+1 RIs are present (yuck)
> - Change it to n+1 only if there are no vers.n RIs present (arguable, but
>   I don't really like it)
> - Leave it as is and use the RI version numbers to figure out whether you can
>   use a particular RI (ie only change it if the EnvelopedData itself changes
>   but not the RI within it)
> 
> The third one seems to be the most sensible.
> 
> Peter.


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA17201 for ietf-smime-bks; Sun, 22 Apr 2001 09:53:12 -0700 (PDT)
Received: from mail.kishurim.k12.il (kishurim.inter.net.il [192.117.129.52]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA17196 for <[e-mail]>; Sun, 22 Apr 2001 09:53:09 -0700 (PDT)
Received: from host (03-112.044.popsite.net [64.24.247.112]) by mail.kishurim.k12.il (8.8.6/8.8.6/PA) with ESMTP id VAA11170; Sun, 22 Apr 2001 21:50:37 +0200 (IST)
Message-Id: <[e-mail]>
From: "Dennis Grant" <[e-mail]>
Subject: Reduce #4BCF
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: Sun, 22 Apr 2001 10:28:22 -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><TITLE>Financial Group</TITLE>
</HEAD><BODY BGCOLOR=3D"#FFFFFF" BACKGROUND=3D"images/177bg1=2Egif" text=3D=
"#330099" link=3D"#0033CC" alink=3D"#000000" vlink=3D"#B89AF5">


<div align=3D"center">
<table width=3D"90%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" bgco=
lor=3D"#FFFFFF">
  <tr>
    <td><!-- New Basic Page Structure - Last Modified: 17 April 2000, by p=
rr =3D^=2E^=3D -->

<table  width=3D"100%" cellpadding=3D"20" cellspacing=3D"0">
  <tr>
    <td>


<!--Place Header-->
<p align=3D"center">&nbsp;</p>



<p align=3D"center"><img src=3D"images/177bar1=2Egif" width=3D"468" height=
=3D"3" /></p>


<!--Company Slogan-->
<p align=3D"center"><STRONG><EM><FONT SIZE=3D"+2" FACE=3D"Arial" color=3D"=
#800080">We Can Save You Money, Guaranteed!</FONT></EM></STRONG></p>


<p><FONT SIZE=3D"+1" FACE=3D"Arial"><font color=3D"#0033CC">Are you lookin=
g for a way to save money on your home mortgage or loan financing?  Then yo=
u should
seriously consider this service=2E</font></FONT></p>



<table border=3D"0" width=3D"100%">
  <tr>
    <td width=3D"7%" align=3D"center"></td>
    <td width=3D"43%"><b><font color=3D"#0033CC">NO REFINANCING</font></b>=
</td>
    <td width=3D"7%" align=3D"center"></td>
    <td width=3D"43%"><font color=3D"#0033CC"><b>NO CREDIT CHECKS</b></fon=
t></td>
  </tr>
  <tr>
    <td width=3D"7%" align=3D"center"></td>
    <td width=3D"43%"><b><font color=3D"#0033CC">NO INCREASE IN MONTHLY PA=
YMENTS</font></b></td>
    <td width=3D"7%" align=3D"center"></td>
    <td width=3D"43%"><font color=3D"#0033CC"><b>NO NEED TO CHANGE LENDERS=
</b></font></td>
  </tr>
  <tr>
    <td width=3D"7%" align=3D"center"></td>
    <td width=3D"43%"><b><font color=3D"#0033CC">NO CLOSING COSTS</font></=
b></td>
    <td width=3D"7%" align=3D"center"></td>
    <td width=3D"43%"></td>
  </tr>
  <tr>
    <td width=3D"7%" align=3D"center"></td>
    <td width=3D"43%"><b><font color=3D"#0033CC">NO POINTS</font></b></td>=

    <td width=3D"7%" align=3D"center"></td>
    <td width=3D"43%"></td>
  </tr>
  <tr>
    <td width=3D"100%" colspan=3D"4" align=3D"center"><font size=3D"4" col=
or=3D"#0033CC"><b>It's not how MUCH money you pay<br>your mortgage company =
that matters,
      its HOW you pay the&nbsp;</b></font></td>
  </tr>
</table>


<br>



<div align=3D"center">
<table>
  <tr>
    <td><b><font size=3D"+1" face=3D"Arial" color=3D"#800080"><span style=3D=
"background-color: #FFFF99">HOW IT WORKS - An
      Example:</span></font>
      </b>
      <p><font size=3D"+1" face=3D"Arial" color=3D"#0033CC"><u>With our he=
lp and
      Without Changing Your Current Mortgage Company We Can Save You</u>: =
We can save you over $66,000 in
      interest <u>AND</u> cut the length of your loan by 6 years on a loan=
 of
      $150,000 for 30 years at 8%!</font></p>
      <p><font size=3D"+1" face=3D"Arial" color=3D"#0033CC">Without our he=
lp a loan of
      $150,000 for 30 years at 8% will cost you $396,234=2E00 and after pa=
ying
      $1,100=2E24 every month for 22 years you still would not yet own hal=
f of
      your home!</font></p>
    </td>
    <td valign=3D"middle" align=3D"center">
</td>
  </tr>
  <tr>
    <td colspan=3D"2">
    </td>
  </tr>
</table>
</div>


<!--Fourth Text Box-->



<!--Special Offer-->


<p align=3D"center"><b><font face=3D"Arial">For a <font color=3D"#FF0000">=
 FREE</font> Mortgage Savings Analysis<br>
                                Please Complete the form below:<br>
                                   All fields must be filled out=2E</font>=
</b></p>


<!--Bottom HR-->
<p align=3D"center"><img src=3D"images/177bar1=2Egif" width=3D"468" height=
=3D"3" /></p>


<form name=3D"form"
  method=3D"post"
  action=3D"mailto:55btr@verizonmail=2Ecom?SUBJECT=3DInternet Lead"
  enctype=3D"text/plain"

<div align=3D"center">
  <center>
<table border=3D"0" width=3D"91%">
  <tr>
    <td width=3D"100%" colspan=3D"2"><b><font color=3D"#800080" size=3D"2"=
>To better
      help us help you, please take a couple short minutes to fill out the=
 form
      below=2E</font></b></td>
  </tr>
  <tr>
    <td width=3D"47%"><b><font color=3D"#0033CC">First Name:</font></b></t=
d>
    <td width=3D"53%"><input type=3D"text" name=3D"first_name" size=3D"34"=
></td>
  </tr>
  <tr>
    <td width=3D"47%"><b><font color=3D"#0033CC">Last Name:</font></b></td=
>
    <td width=3D"53%"><input type=3D"text" name=3D"last_name" size=3D"34">=
</td>
  </tr>
  <tr>
    <td width=3D"47%"><b><font color=3D"#0033CC">Email Address:</font></b>=
</td>
    <td width=3D"53%"><input type=3D"text" name=3D"email" size=3D"34"></td=
>
  </tr>
  <tr>
    <td width=3D"47%"><b><font color=3D"#0033CC">Address:</font></b></td>
    <td width=3D"53%"><input type=3D"text" name=3D"address" size=3D"34"></=
td>
  </tr>
  <tr>
    <td width=3D"47%"><b><font color=3D"#0033CC">City:</font></b></td>
    <td width=3D"53%"><input type=3D"text" name=3D"city" size=3D"34"></td>=

  </tr>
  <tr>
    <td width=3D"47%"><b><font color=3D"#0033CC">State:</font></b></td>
    <td width=3D"53%"><FONT face=3DArial><SELECT name=3Dstate 
                  size=3D1> <OPTION>AL</OPTION> <OPTION>AK</OPTION> 
                    <OPTION>AZ</OPTION> <OPTION>AR</OPTION> <OPTION 
                    selected>CA</OPTION> <OPTION>CO</OPTION> <OPTION>CT</O=
PTION> 
                    <OPTION>DE</OPTION> <OPTION>DC</OPTION> <OPTION>FL</OP=
TION> 
                    <OPTION>GA</OPTION> <OPTION>HI</OPTION> <OPTION>ID</OP=
TION> 
                    <OPTION>IL</OPTION> <OPTION>IN</OPTION> <OPTION>IA</OP=
TION> 
                    <OPTION>KS</OPTION> <OPTION>KY</OPTION> <OPTION>LA</OP=
TION> 
                    <OPTION>ME</OPTION> <OPTION>MD</OPTION> <OPTION>MA</OP=
TION> 
                    <OPTION>MI</OPTION> <OPTION>MN</OPTION> <OPTION>MS</OP=
TION> 
                    <OPTION>MO</OPTION> <OPTION>MT</OPTION> <OPTION>NE</OP=
TION> 
                    <OPTION>NV</OPTION> <OPTION>NH</OPTION> <OPTION>NJ</OP=
TION> 
                    <OPTION>NM</OPTION> <OPTION>NY</OPTION> <OPTION>NC</OP=
TION> 
                    <OPTION>ND</OPTION> <OPTION>OH</OPTION> <OPTION>OK</OP=
TION> 
                    <OPTION>OR</OPTION> <OPTION>PA</OPTION> <OPTION>RI</OP=
TION> 
                    <OPTION>SC</OPTION> <OPTION>SD</OPTION> <OPTION>TN</OP=
TION> 
                    <OPTION>TX</OPTION> <OPTION>UT</OPTION> <OPTION>VT</OP=
TION> 
                    <OPTION>VI</OPTION> <OPTION>VA</OPTION> <OPTION>WA</OP=
TION> 
                    <OPTION>WV</OPTION> <OPTION>WI</OPTION> 
                  <OPTION>WY</OPTION></SELECT></FONT></td>
  </tr>
  <tr>
    <td width=3D"47%"><b><font color=3D"#0033CC">Zip Code:</font></b></td>=

    <td width=3D"53%"><input type=3D"text" name=3D"zip" size=3D"34"></td>
  </tr>
  <tr>
    <td width=3D"47%"><b><font color=3D"#0033CC">Work Phone Number:</font>=
</b></td>
    <td width=3D"53%"><input type=3D"text" name=3D"work_number" size=3D"34=
"></td>
  </tr>
  <tr>
    <td width=3D"47%"><b><font color=3D"#0033CC">Home Phone Number:</font>=
</b></td>
    <td width=3D"53%"><input type=3D"text" name=3D"home_number" size=3D"34=
"></td>
  </tr>
  <tr>
    <td width=3D"47%"><b><font color=3D"#0033CC">Best Time and place to Ca=
ll:</font></b></td>
    <td width=3D"53%"><input type=3D"text" name=3D"best_time" size=3D"34">=
</td>
  </tr>
  <tr>
    <td width=3D"47%"><b><font color=3D"#0033CC">Type of House You Own:</f=
ont></b></td>
    <td width=3D"53%"><FONT face=3DArial><SELECT 
                  name=3Dproperty_type size=3D1> <OPTION selected 
                    value=3D"Single Family">Single Family</OPTION> <OPTION=
 
                    value=3DCondo>Condo</OPTION> <OPTION 
                    value=3DTownhouse>Townhouse</OPTION> <OPTION 
                    value=3DMulti-Family>Multi-Family</OPTION></SELECT></F=
ONT></td>
  </tr>
  <tr>
    <td width=3D"47%"><b><font color=3D"#0033CC">Current Value of Home:</f=
ont></b></td>
    <td width=3D"53%"><input type=3D"text" name=3D"current_value" size=3D"=
34"></td>
  </tr>
  <tr>
    <td width=3D"47%"><b><font color=3D"#0033CC">Purchase Price of Home:</=
font></b></td>
    <td width=3D"53%"><input type=3D"text" name=3D"purchase_price" size=3D=
"34"></td>
  </tr>
  <tr>
    <td width=3D"47%"><b><font color=3D"#0033CC">Purchase Date of Home</fo=
nt></b> <i><font color=3D"#FF0000">(mm/dd/yy)</font></i></td>
    <td width=3D"53%"><input type=3D"text" name=3D"purchase_date" size=3D"=
34"></td>
  </tr>
  <tr>
    <td width=3D"47%"><b><font color=3D"#0033CC">Balance Left on Mortgage:=
</font></b></td>
    <td width=3D"53%"><input type=3D"text" name=3D"mortgage_balance" size=3D=
"34"></td>
  </tr>
  <tr>
    <td width=3D"47%"><font color=3D"#0033CC"><b>How Long Have You Had You=
r Current Loan?</b></font></td>
    <td width=3D"53%"><input type=3D"text" name=3D"how_long_current_loan" =
size=3D"34"></td>
  </tr>
  <tr>
    <td width=3D"47%"><font color=3D"#0033CC"><b>How Many Months/Years Hav=
e Been Paid On Loan So Far?</b></font></td>
    <td width=3D"53%"><input type=3D"text" name=3D"paid_on_loan_thus_far" =
size=3D"34"></td>
  </tr>
  <tr>
    <td width=3D"47%"><b><font color=3D"#0033CC">Interest Rate:</font></b>=
</td>
    <td width=3D"53%"><input type=3D"text" name=3D"interest_rate" size=3D"=
8"></td>
  </tr>
  <tr>
    <td width=3D"47%"><b><font color=3D"#0033CC">Fixed or Adjustable Rate?=
</font></b></td>
    <td width=3D"53%"><FONT face=3DArial><SELECT 
                  name=3Dfixed_or_adjustable size=3D1> <OPTION 
                    value=3DFixed>Fixed</OPTION> <OPTION selected 
                    value=3DAdjustable>Adjustable</OPTION> <OPTION 
                    value=3D"Not sure">Not sure</OPTION></SELECT></FONT></=
td>
  </tr>
  <tr>
    <td width=3D"47%"><b><font color=3D"#0033CC">Your Monthly Payment:</fo=
nt></b></td>
    <td width=3D"53%"><input type=3D"text" name=3D"monthly_pymt" size=3D"3=
4"></td>
  </tr>
  <tr>
    <td width=3D"47%"><b><font color=3D"#0033CC">Are You Behind on Payment=
s?</font></b></td>
    <td width=3D"53%"><FONT face=3DArial><SELECT name=3Dbehind 
                  size=3D1> <OPTION value=3DY>Yes</OPTION> <OPTION selecte=
d 
                    value=3DN>No</OPTION></SELECT></FONT></td>
  </tr>
  <tr>
    <td width=3D"47%"><b><font color=3D"#0033CC">Please Rate Your Credit:<=
/font></b></td>
    <td width=3D"53%"><FONT face=3DArial><SELECT name=3Dcredit 
                  size=3D1> <OPTION value=3DPoor selected>Poor</OPTION> <O=
PTION 
                    value=3DFair>Fair</OPTION> <OPTION 
                    value=3DGood>Good</OPTION> 
                  <OPTION value=3D"Excellent">Excellent</OPTION></SELECT><=
/FONT></td>
  </tr>
  <tr>
    <td width=3D"47%"><b><font color=3D"#0033CC">Additional Information Yo=
u<br>Think May be Helpful:</font></b></td>
    <td width=3D"53%"><textarea rows=3D"3" name=3D"more_info" cols=3D"29">=
</textarea></td>
  </tr>
  <tr>
    <td width=3D"100%" colspan=3D"2" align=3D"center"><input type=3D"submi=
t" value=3D"Submit" name=3D"B1"></td>
  </tr>
</table>

  </center>

    </td>
  </tr>
</table>
      <p align=3D"center"><FONT face=3DArial size=3D"2" color=3D"#800080">=
<b>All information collected is 
            treated as strictly confidential and will only be used for the=
 
            purposes of real estate reduction and refinancing services=2E<=
br>We will never sell
            your name to a third party marketer=2E</b></FONT><br>
      </p>
    </td>
  </tr>
  <tr>
    <td>
      <p align=3D"center"></p>
    </td>
  </tr>
  <tr>
    <td>
      <table border=3D"0" width=3D"100%">
        <tr>
          <td width=3D"33%">
            <table border=3D"0" width=3D"100%">
              <tr>
                <td width=3D"43%"></td>
                <td width=3D"57%">
                  <p align=3D"center"></td>
              </tr>
            </table>
          </td>
          <td width=3D"33%">
            <p align=3D"center"></td>
          <td width=3D"34%">
            <p align=3D"center"></td>
        </tr>
      </table>
    </td>
  </tr>
</table>
<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:mm89bk@netscape=2Enet?subject=3Dremove">Click
 Here</a></font></font></b>


</div></BODY></HTML>


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

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





Received: by above.proper.com (8.9.3/8.9.3) id NAA05252 for ietf-smime-bks; Fri, 20 Apr 2001 13:04:08 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id NAA05234 for <[e-mail]>; Fri, 20 Apr 2001 13:04:02 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 20 Apr 2001 20:04:07 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA03032 for <[e-mail]>; Fri, 20 Apr 2001 16:04:04 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id <HK1AN9FF>; Fri, 20 Apr 2001 16:04:00 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.122]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HK1AN919; Fri, 20 Apr 2001 16:03:45 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 20 Apr 2001 14:12:56 -0400
Subject: RE: S/MIME ECC Doc
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>

Simon:

I want to raise a few minor concerns/questions.

(1) The specification only employs SHA-1. Should it be extended to include 
to SHA-256 in anticipation of 128-bit AES keys?

(2) Does the 1-pass D-H scheme use co-factor multiplication? I understand 
that it is possible to do it done with or without co-factor multiplication, 
so I am really seeking clarification here.  Are there IPR issues regarding 
the choice?

(3) Can you say something about the unknown key-share attack on MQV?  I 
understand that this vulnerability can be avoided by explicit key 
authentication.  A paragraph in the Security Considerations section should 
be sufficient.

(4) Section 3.2.2. "Parity bits adjusted according to the keywrap 
algorithm" is rather vague.  Please extract the appropriate text from RFC 2630.

Thanks,
     Russ 


Received: by above.proper.com (8.9.3/8.9.3) id PAA03295 for ietf-smime-bks; Thu, 19 Apr 2001 15:07:44 -0700 (PDT)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA03290 for <[e-mail]>; Thu, 19 Apr 2001 15:07:42 -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 KAA26026; Fri, 20 Apr 2001 10:07:37 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98771805604118>; Fri, 20 Apr 2001 10:07:36 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  S/MIME version number and Attribute Certificates
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Fri, 20 Apr 2001 10:07:36 (NZST)
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>

"Pawling, John" <[e-mail]> writes:

>I doubt if many implementations check the EnvelopedData version value before
>attempting to decode the hex data.  A new version number would have assisted
>with debugging and error reporting, but it is probably not worth the effort to
>change the specs and implementations to populate the new version value.

My code does (OK, it's not just pedantic, it's truly anal-retentive :-),
whether this was a good idea or not would have depended on how EnvelopedData
versions are interpreted.  If the EnvelopedData version was incremented
whenever a new RecipientInfo was added then it's bad, because adding a single
vers.n+1 RI to a bunch of vers.n RIs will change the EnvelopedData version even
though there are vers.n RIs there which could be processed (that is, the code
could still process the EnvelopedData except that the presence of the vers.n+1
value for the EnvelopedData would stop it).  OTOH if the EnvelopedData version
is only incremented when the overall structure of the EnvelopedData is changed
then it's fine, because it won't try and decode something in a completely
different format. There are actually quite a variety of possibilities:

- Change it to n+1 if any n+1 RIs are present (yuck)
- Change it to n+1 only if there are no vers.n RIs present (arguable, but
  I don't really like it)
- Leave it as is and use the RI version numbers to figure out whether you can
  use a particular RI (ie only change it if the EnvelopedData itself changes
  but not the RI within it)

The third one seems to be the most sensible.

Peter.



Received: by above.proper.com (8.9.3/8.9.3) id OAA02535 for ietf-smime-bks; Thu, 19 Apr 2001 14:42:33 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA02531 for <[e-mail]>; Thu, 19 Apr 2001 14:42:32 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <H95FZMJ5>; Thu, 19 Apr 2001 17:43:31 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: S/MIME version number and Attribute Certificates 
Date: Thu, 19 Apr 2001 17:43: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,

I retract my recommendation to assign a new value for use in the
son-of-RFC2630 SignedData and EnvelopedData version fields due to the
incompatibility of the 1997 and 2000 Attribute Certificate (AC) syntaxes.
If 1997 ACs have not been operationally used in SignedData and EnvelopedData
objects (which seems to be the case based on the lack of feedback from the
list), then a new version value is unnecessary.     

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


Received: by above.proper.com (8.9.3/8.9.3) id OAA29178 for ietf-smime-bks; Thu, 19 Apr 2001 14:07:06 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA29174 for <[e-mail]>; Thu, 19 Apr 2001 14:07:05 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <H95FZMBD>; Thu, 19 Apr 2001 17:08:04 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: RE: S/MIME version number
Date: Thu, 19 Apr 2001 17:07:56 -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>

Peter,

RFC2630 (and I assume son-of-RFC2630) references the 1988 ASN.1 specs.
Given that fact, adding the password-based encryption option to the
RecipientInfo CHOICE IS a change to the EnvelopedData syntax.  Not all
S/MIME implementations include the flexibility to skip unknown-tagged items
in a CHOICE.  For example, the S/MIME Freeware Library uses the Enhanced
SNACC Compiler and library to implement the S/MIME v3 specs.  The Enhanced
SNACC library will return an ASN.1 decode error if it encounters an
unknown-tagged item in a CHOICE.  I am sure there are other implementations
that would also return an error under those conditions.

Having said all of that, I retract my recommendation to assign a new value
for use in the EnvelopedData version field due to the addition of the
password-based encryption option to the RecipientInfo CHOICE.  I doubt if
many implementations check the EnvelopedData version value before attempting
to decode the hex data.  A new version number would have assisted with
debugging and error reporting, but it is probably not worth the effort to
change the specs and implementations to populate the new version value.  

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

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Thursday, April 19, 2001 4:17 AM
To: [e-mail]; [e-mail]
Subject: RE: S/MIME version number


"Pawling, John" <[e-mail]>

>I believe that when an ASN.1 syntax is changed that includes a version
field,
>then a new version number should be assigned to indicate the new ASN.1
syntax.

It doesn't really change it though, it just adds another option to the
CHOICE.
I would hope that any software which works with these things would just skip
the unknown-tagged item (having said that my own code will reject it because
I
tend to be overly pedantic in my checking, changing a constant and
recompiling
will fix this behaviour).  On the whole I don't know whether changing the
version number will have any useful effect, because anything which rejects a
new CHOICE tag is just as likely to reject a new version number (any
comments
from implementors?  If making either change will break apps equally then I'd
vote to leave the version number alone).

(Just for form's sake, I'll add my standard gripe that if we were using any
 kind of non-archaic ASN.1 you could just add '...' to the CHOICE and this
 whole issue would go away).

Peter.


Received: by above.proper.com (8.9.3/8.9.3) id OAB18076 for ietf-smime-bks; Wed, 18 Apr 2001 14:45:00 -0700 (PDT)
Received: from smtp-a.capu.net (IDENT:[e-mail] [205.177.76.122]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA18071 for <[e-mail]>; Wed, 18 Apr 2001 14:44:58 -0700 (PDT)
Received: from ieca.com (dial-216-66.capu.net [64.50.216.66]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id RAA24728; Wed, 18 Apr 2001 17:44:56 -0400
Message-ID: <[e-mail]>
Date: Wed, 18 Apr 2001 17:44:56 -0400
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: Russ Housley <[e-mail]>
CC: IETF S/MIME WG <[e-mail]>
Subject: Re: Revised section 2.5 of draft-ietf-smime-x400transport-01
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

    I concur with your comments.  More detailed responses in line.

Chris

_________________________

Russ Housley wrote:

> It took me two or three readings to understand this "table."  Please
> replace "Security" with "CMS protection content type."

Okay.

> >      cert-management  id-eit-certManagement
> >      SignedData       none
>
> Instead of "none," I personally prefer "empty (zero length content)."
>

Okay, I think this is your phrasing is less ambiguous.


> >In order that consistency can be obtained with future, the
> >following guidelines should be followed when assigning a new
> >values of EIT.
>
> I do not understand the introductory phrase.  Is there a word missing?
>

Actually, I stole that bit of text from 3.2.2. of MSG.  I guess I would
propose the following to replace that sentence in this context.

     In order that consistency can be obtained in future S/MIME EIT
     assignments, the following guidelines should be followed when
     assigning a new values of EIT.

I think that is what was meant by the original text.

Chris





Received: by above.proper.com (8.9.3/8.9.3) id NAA10234 for ietf-smime-bks; Wed, 18 Apr 2001 13:17:26 -0700 (PDT)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA10227 for <[e-mail]>; Wed, 18 Apr 2001 13:17:24 -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 IAA14616; Thu, 19 Apr 2001 08:17:22 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98762504223911>; Thu, 19 Apr 2001 08:17:22 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: S/MIME version number
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Thu, 19 Apr 2001 08:17:22 (NZST)
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>

"Pawling, John" <[e-mail]>

>I believe that when an ASN.1 syntax is changed that includes a version field,
>then a new version number should be assigned to indicate the new ASN.1 syntax.

It doesn't really change it though, it just adds another option to the CHOICE.
I would hope that any software which works with these things would just skip
the unknown-tagged item (having said that my own code will reject it because I
tend to be overly pedantic in my checking, changing a constant and recompiling
will fix this behaviour).  On the whole I don't know whether changing the
version number will have any useful effect, because anything which rejects a
new CHOICE tag is just as likely to reject a new version number (any comments
from implementors?  If making either change will break apps equally then I'd
vote to leave the version number alone).

(Just for form's sake, I'll add my standard gripe that if we were using any
 kind of non-archaic ASN.1 you could just add '...' to the CHOICE and this
 whole issue would go away).

Peter.



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA08043 for ietf-smime-bks; Wed, 18 Apr 2001 12:55:13 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA08026 for <[e-mail]>; Wed, 18 Apr 2001 12:55:06 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 Apr 2001 19:52:28 UT
Received: from HOUSLEY-LAP.rsasecurity.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA03350; Wed, 18 Apr 2001 15:54:56 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 18 Apr 2001 13:01:11 -0400
To: "Bonatti, Chris" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Revised section 2.5 of draft-ietf-smime-x400transport-01
Cc: IETF S/MIME WG <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chris:


I have a few comments on your proposed text.  See below.

If I do not hear concerns raised in the next few days, I will assign the 
OIDs that Chris needs to proceed on this path.

Russ


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

It took me two or three readings to understand this "table."  Please 
replace "Security" with "CMS protection content type."


>      enveloped-data   id-eit-envelopedData
>      EnvelopedData    Data
>
>      signed-data      id-eit-signedData
>      SignedData       Data
>
>      cert-management  id-eit-certManagement
>      SignedData       none

Instead of "none," I personally prefer "empty (zero length content)."


>      signed-receipt   id-eit-signedReceipt
>      SignedData       Receipt
>
>      enveloped-x400   id-eit-envelopedx400
>      EnvelopedData    X.400 content
>
>      signed-x400      id-eit-signedx400
>      SignedData       X.400 content
>
>Sending agents SHOULD include the appropriate S/MIME EIT OID
>value.  Receiving agents SHOULD recognize S/MIME OID values in
>the EITs field, and process the message appropriately according
>to local procedures.
>
>In order that consistency can be obtained with future, the

I do not understand the introductory phrase.  Is there a word missing?

>following guidelines should be followed when assigning a new
>values of EIT.  Values assigned for S/MIME EITs should correspond
>to assigned smime-type values on a one to one basis.  The
>restrictions of section 3.2.2 of [MSG] therefore apply.  S/MIME
>EIT values may coexist with other EIT values intended to further
>qualify the makeup of the protected content.
>
>2.5.1 Enveloped Data
>
>The enveloped data EIT indicates that the X.400 content field
>contains a MIME type that has been protected by the CMS
>Enveloped-data content type in accordance with [MSG]. The
>resulting enveloped data CMS content is conveyed in accordance
>with section 2.2. This EIT should be indicated by the following
>OID value:
>
>     id-eit-envelopedData  OBJECT IDENTIFIER ::=
>         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
>         pkcs-9(9) smime(16) eits(***) envelopedData(0) }
>
>2.5.2 Signed Data
>
>The signed data EIT indicates that the X.400 content field
>contains a MIME type that has been protected by the CMS
>Signed-data content type in accordance with [MSG]. The resulting
>signed data CMS content is conveyed in accordance with section
>2.2. This EIT should be indicated by the following OID value:
>
>    id-eit-signedData  OBJECT IDENTIFIER ::=
>         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
>         pkcs-9(9) smime(16) eits(***) signedData(1) }
>
>2.5.3 Certificate Management
>
>The certificate management message is used to transport
>certificates and/or CRLs, such as in response to a registration
>request. The certificate management message consists of a single
>instance of CMS content of type Signed-data.  The
>encapContentInfo eContent field MUST be absent and signerInfos
>field MUST be empty. The resulting certificate management CMS
>content is conveyed in accordance with section 2.2. This EIT
>should be indicated by the following OID value:
>
>     id-eit-certManagement  OBJECT IDENTIFIER ::=
>         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
>         pkcs-9(9) smime(16) eits(***) certManagement(2) }
>
>2.5.4 Signed Receipt
>
>The signed receipt EIT indicates that the X.400 content field
>contains a Receipt content that has been protected by the CMS
>Signed-data content type in accordance with [ESS]. The resulting
>signed data CMS content is conveyed in accordance with section
>2.2. This EIT should be indicated by the following OID value:
>
>     id-eit-signedReceipt  OBJECT IDENTIFIER ::=
>         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
>         pkcs-9(9) smime(16) eits(***) signedReceipt(3) }
>
>2.5.5 Enveloped X.400
>
>The enveloped X.400 EIT indicates that the X.400 content field
>contains X.400 content that has been protected by the CMS
>Enveloped-data content type in accordance with [X400WRAP]. The
>resulting enveloped X.400 CMS content is conveyed in accordance
>with section 2.2. This EIT should be indicated by the following
>OID value:
>
>     id-eit-envelopedX400  OBJECT IDENTIFIER ::=
>         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
>         pkcs-9(9) smime(16) eits(***) envelopedX400(4) }
>
>2.5.6 Signed X.400
>
>The signed X.400 EIT indicates that the X.400 content field
>contains X.400 content that has been protected by the CMS
>Signed-data content type in accordance with [X400WRAP]. The
>resulting signed X.400 CMS content is conveyed in accordance with
>section 2.2. This EIT should be indicated by the following OID
>value:
>
>     id-eit-signedX400  OBJECT IDENTIFIER ::=
>         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
>         pkcs-9(9) smime(16) eits(***) signedX400(5) }



Received: by above.proper.com (8.9.3/8.9.3) id JAA23347 for ietf-smime-bks; Wed, 18 Apr 2001 09:04:37 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA23343 for <[e-mail]>; Wed, 18 Apr 2001 09:04:36 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <H95FY0Y5>; Wed, 18 Apr 2001 12:05:34 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: RE: S/MIME version number
Date: Wed, 18 Apr 2001 12:05:32 -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>

Peter,

I made a similar statement in my original response to Blake's message: 

"The other option is that the "son-of-RFC 2630" CMSVersion number usage
could
remain the same as defined in RFC 2630 if the working group assumes that
1997 ACs have not been operationally used in SignedData and EnvelopedData
objects.  I do not know if that is a safe assumption."

I still do not know if that is a safe assumption.

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


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, April 18, 2001 10:41 PM
To: [e-mail]; [e-mail]
Subject: RE: S/MIME version number


"Pawling, John" <[e-mail]> writes:

>I agree that there are work-arounds for this problem, but I prefer that we
>define a clean strategy (i.e. new SignedData and EnvelopedData version
>numbers), rather than needing to resort to work-arounds.

Given that use of ACs is currently essentially nonexistant and that ACs used
with S/MIME are probably[0] completely nonexistant, why is this an issue?
It's
not as if it's going to break some vast installed base of software if we
just
say that ACs use the 2000 syntax and leave the version numbers alone.

Peter.

[0] Added as a safety catch just in case there is some solitary
implementation
    floating around out there.


Received: by above.proper.com (8.9.3/8.9.3) id HAA12271 for ietf-smime-bks; Wed, 18 Apr 2001 07:41:24 -0700 (PDT)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA12267 for <[e-mail]>; Wed, 18 Apr 2001 07:41:22 -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 CAA16316; Thu, 19 Apr 2001 02:41:16 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98760487622328>; Thu, 19 Apr 2001 02:41:16 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: S/MIME version number
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Thu, 19 Apr 2001 02:41:16 (NZST)
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>

"Pawling, John" <[e-mail]> writes:

>I agree that there are work-arounds for this problem, but I prefer that we
>define a clean strategy (i.e. new SignedData and EnvelopedData version
>numbers), rather than needing to resort to work-arounds.

Given that use of ACs is currently essentially nonexistant and that ACs used
with S/MIME are probably[0] completely nonexistant, why is this an issue?  It's
not as if it's going to break some vast installed base of software if we just
say that ACs use the 2000 syntax and leave the version numbers alone.

Peter.

[0] Added as a safety catch just in case there is some solitary implementation
    floating around out there.



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA21653 for ietf-smime-bks; Tue, 17 Apr 2001 14:43:30 -0700 (PDT)
Received: from netlink.co.nz (mako.netlink.co.nz [202.20.93.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA21647 for <[e-mail]>; Tue, 17 Apr 2001 14:43:28 -0700 (PDT)
Received: from ronsnotebook (128i-cl128.netlink.net.nz [203.97.144.128]) by netlink.co.nz (8.9.3/8.9.3) with SMTP id JAA24568 for <[e-mail]>; Wed, 18 Apr 2001 09:43:30 +1200 (NZST)
From: "Ron Segal" <[e-mail]>
To: <[e-mail]>
Subject: DOMSEC
Date: Wed, 18 Apr 2001 09:46:49 +1200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0028_01C0C7EC.7D8A0360"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0028_01C0C7EC.7D8A0360
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Folks

This is in response to a message (reproduced below) from Anders Rundgren re
DOMSEC products and certificates, which was forwarded to me by a government
user of our products.

1. Any working implementations?

We supply a product called MailMarshal Secure, which is an e-mail gateway
that implements S/MIME domain security.  The product is being used by New
Zealand government agencies to sign and encrypt e-mail messages being sent
between agencies via the Internet.  The messages are signed/verified and
encrypted/decrypted by the gateway itself using domain certificates.  This
means that messages coming into a gateway can be content and virus checked
before being passed-on to the recipient behind the gateway. The gateway
incorporates a flexible rules engine that can decide the circumstances in
which to sign and/or encrypt messages, or indeed whether to block sensitive
messages, perhaps being sent to a list containing addresses with unsecured
links.  The product is manufactured in New Zealand and sold worldwide.  I
can provide further information if anybody is interested.

2. A possibility to send me an entire DOMSEC-compatible S/MIME container.

Yes, I am sure that we can arrange to send you a signed-message from a
MailMarshal Secure gateway.

Q1. If an e-mail server is not set-up for DOMSEC will the end-destination
still get the message without interoperability problems.

Presumably this depends on the e-mail server. Exchange by default of course
strips signatures from messages.  It doesn't matter with the MailMarshal
Secure gateway, which logically sits between an SMTP e-mail server and the
firewall.  Messages passed to the e-mail server from the gateway are
unsigned, in the clear, so the issue does not arise. The gateway itself is
(optionally depending on rules configuration) able to annotate or 'stamp' a
message to indicate a correct signature or otherwise.  The gateway can also
pass through signed/encrypted messages, from a desktop say, providing the
rules are configured to enable pass through.

Q2: Are there any TTPs issuing suitable certificates today in the same way
as they do for Web (domain)-servers?

We are New Zealand's first public Certification Authority.  We have been
providing certificates to enable the MailMarshal Secure gateways being
deployed by the NZ government to be authenticated.

Q3: Couldn't a single certificate actually serve both of these purposes?

Yes, the certs that we supply for use by gateways are our standards
compliant X.509 v3 SSL server certs (the same ones that we supply for secure
web servers).  These are configured to adhere to the DOMSEC naming
standards, that the Common Name must be 'domain confidentiality authority'
and e-mail address must be domain-confidentiality-authority@domain.

I hope that this information is useful and not too salesy. We helped to
design MailMarshal Secure and are enthusiastic about it as a product.  By
the way the gateway can also handle signed/encrypted mail to/from S/MIME
desktops.  It does this by implementing what I think is a unique mechanism
of using 'proxy certificates'.  A proxy certificate is generated by the
gateway for each user that wishes to send a signed message.  Proxy certs are
all signed by the gateway's common private key but contain the end-user's
e-mail address so that an S/MIME desktop will correctly verify the address
in the cert against sender's address (in this case of course the whole
address being checked, not just the domain).  The use of the gateway private
key enables the gateway to do the signing and also to decrypt messages
encrypted using proxy certificates.  In effect this provides the means for
an organisation to send signed e-mail messages as a transparent service,
i.e. from desktops that do not support S/MIME and without user intervention.

If anybody would like further information please contact me at
[e-mail]

All the best

Ron


Hi
I think DOMSEC is a very powerful concept but it does not seem to be widely
adapted
and the S/MIME-list contains almost no discussions.

What I wonder if you out there have:

1. Any working implementations

2. A possibility to send me an entire signed DOMSEC-compatible S/MIME
container

Technical questions regarding DOMSEC:

Q1: If an e-mail server is not set-up for DOMSEC will the end-destination
still get
the message without interoperability problems?

Q2: Are there any TTPs issuing suitable certificates today in the same way
as they do for Web (domain)-servers?

Q3: Couldn't a single certificate actually serve both of these purposes?

Regards
Anders Rundgren
X-OBI

--------------
Ron Segal
Business Development Manager
Baycorp ID Services Ltd
PO Box 5052, Wellington, New Zealand

Mailto: [e-mail]
Tel:   +64 (4)  499 4231
DD:    +64 (4)  499 4261
Mob:   [phone]
Fax:   +64 (4)  499 4233
Web:   http://www.baycorpid.com


If you received a warning on reading this email, please go to
<http://www.baycorpid.com/settings/email.asp> to update your settings

------=_NextPart_000_0028_01C0C7EC.7D8A0360
Content-Type: text/x-vcard;
	name="Ron Segal.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Ron Segal.vcf"

BEGIN:VCARD
VERSION:2.1
N:Segal;Ron
FN:Ron Segal
ORG:Baycorp ID Services
TITLE:Business Development Manager
TEL;WORK;VOICE:[phone]
TEL;CELL;VOICE:[phone]
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Level 1=3D0D=3D0ALandcorp =
House=3D0D=3D0A101 Lambton Quay=3D0D=3D0APO Box 5052;Welling=3D
ton;;;New Zealand
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Level 1=3D0D=3D0ALandcorp =
House=3D0D=3D0A101 Lambton Quay=3D0D=3D0APO Box 5052=3D0D=3D0AWell=3D
ington=3D0D=3D0ANew Zealand
URL:
URL:http://www.baycorpid.com
KEY;X509;ENCODING=3DBASE64:
    =
MIIGdzCCBV+gAwIBAgIEOhwthjANBgkqhkiG9w0BAQUFADB7MQswCQYDVQQGEwJOWjEgMB4G
    =
A1UEChMXQmF5Y29ycCBJRCBTZXJ2aWNlcyBMdGQxGTAXBgNVBAsTEEJheWNvcnAgUGFzc3Bv
    =
cnQxLzAtBgNVBAMTJkJheWNvcnAgUGFzc3BvcnQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4X
    =
DTAwMTEyMjIwMzMxMFoXDTAxMTEyNzIwMzMxMFowfDELMAkGA1UEBhMCTloxCjAIBgNVBAgT
    =
AS0xEzARBgNVBAcTCldlbGxpbmd0b24xEDAOBgNVBAoTB0JheWNvcnAxEjAQBgNVBAMTCVJv
    =
biBTZWdhbDEmMCQGCSqGSIb3DQEJARYXcm9uLnNlZ2FsQGJheWNvcnBpZC5jb20wgZ8wDQYJ
    =
KoZIhvcNAQEBBQADgY0AMIGJAoGBANRQxdVFIMgxT5W45/I5HSGKPCCKfijydisE8fhqc/uh
    =
Vqn9wE+CwCMJKKgUM5pH3g+ZyTbBKjctkSDOcmuN2aNGm1EPZq1xORI6byWmd6S9jb5/I2vt
    =
IeqhWQC3MuVhrBFFuOsu1JBiGLmxaHg71ti/b97q50zA/hIOgDAuixtfAgMBAAGjggOEMIID
    =
gDAiBgkrBgEEAZtYAAEEFRYTUm9uYWxkIFNhbXVlbCBTZWdhbDAOBgNVHQ8BAf8EBAMCA/gw
    =
UQYDVR0lBEowSAYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBAYIKwYBBQUHAwUGCCsG
    =
AQUFBwMGBggrBgEFBQcDBwYKKwYBBAGCNwoDBDA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8v
    =
d3d3LmJheWNvcnBpZC5jb20vY3JsL3Bhc3Nwb3J0LmNybDAZBgNVHQkEEjAQMA4GA1UEBDEH
    =
EwVTZWdhbDAiBgNVHREEGzAZgRdyb24uc2VnYWxAYmF5Y29ycGlkLmNvbTCCAfIGA1UdIASC
    =
AekwggHlMIIB4QYMKwYBBAGbWAIBAgECMIIBzzCCAZoGCCsGAQUFBwICMIIBjBqCAYhUaGUg
    =
cmlnaHRzLCBvYmxpZ2F0aW9ucyBhbmQgbGlhYmlsaXRpZXMgb2YgdGhlIFN1YmplY3QsIEJh
    =
eWNvcnAgSUQgU2VydmljZXMgYW5kIGFueSByZWx5aW5nIHBhcnR5IGFyZSBzcGVjaWZpZWQg
    =
aW4gdGhlIEJheWNvcnAgUGFzc3BvcnQgQ2VydGlmaWNhdGlvbiBQcmFjdGlzZSBTdGF0ZW1l
    =
bnQuIFlvdSBtdXN0IGVuc3VyZSB0aGF0IHRoaXMgY2VydGlmaWNhdGUgaXMgbm90IHN1c3Bl
    =
bmRlZCBvciByZXZva2VkOyBjb21wbHkgd2l0aCB0aGUgc3BlY2lmaWNhdGlvbnMgaW4gaXRz
    =
IEtleSBVc2FnZSBmaWVsZDsgYWRoZXJlIHRvIEJheWNvcnAgSUQgU2VydmljZXMnIFByaXZh
    =
Y3kgUG9saWN5LiBGdXJ0aGVyIGRldGFpbCBpcyBhdmFpbGFibGUgZnJvbSBCYXljb3JwIElE
    =
IFNlcnZpY2VzOjAvBggrBgEFBQcCARYjaHR0cDovL3d3dy5iYXljb3JwaWQuY29tL3JlcG9z
    =
aXRvcnkwOwYIKwYBBQUHAQEELzAtMCsGCCsGAQUFBzABhh9odHRwOi8vY2VydHN0YXR1cy5i
    =
YXljb3JwaWQuY29tMB8GA1UdIwQYMBaAFHlNfEwOah9O+VNsNHtQxa6cxvR+MB0GA1UdDgQW
    =
BBSQs4oU5iFIMqGm5FFzDKWqV0NDlzAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUAA4IBAQCM
    =
mcZU4Svrle0oqf8/r080V7/KW/7aaoYk//s161jKoWUs7WfmZzbyOgUQPeIuzk3bqfD9xN2E
    =
kfDkaMiPDg5xZ8O/WKnzV2CLYDZrgyoFZ/o0ol+g1akXdAsgp3U73wk8kc7PfcpttSAQy7Mc
    =
78Ej+kaU1TUcyaqsJU6+cryb0EfixPosZpUgx8SZcx+KuRej5ZGHk0zCCsVWNS91noMlkN95
    =
ZP5fkzReeX2xrFmVfqTNawYBywrrvY4ULADRAVFrbqU4h2152KZKsALEpSFZqntLZlR8izqA
    dz/8d+u0KwTLkSPRJiWemL2iyFkU5H6qQoOLuLEQCQiRNxiblLlI


EMAIL;PREF;INTERNET:[e-mail]
REV:20010130T034848Z
END:VCARD

------=_NextPart_000_0028_01C0C7EC.7D8A0360--



Received: by above.proper.com (8.9.3/8.9.3) id CAA25039 for ietf-smime-bks; Tue, 17 Apr 2001 02:42:18 -0700 (PDT)
Received: from mail.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by above.proper.com (8.9.3/8.9.3) with SMTP id CAA25031 for <[e-mail]>; Tue, 17 Apr 2001 02:42:16 -0700 (PDT)
Received: (qmail 22364 invoked from network); 17 Apr 2001 09:42:14 -0000
Received: from cray.eris.dera.gov.uk (HELO mailhost.eris.dera.gov.uk) (128.98.2.7) by ens0.eris.dera.gov.uk with SMTP; 17 Apr 2001 09:42:14 -0000
Received: (qmail 19605 invoked from network); 17 Apr 2001 09:42:13 -0000
Received: from wottaway.eris.dera.gov.uk (HELO wottaway) (128.98.10.192) by mailhost.eris.dera.gov.uk with SMTP; 17 Apr 2001 09:42:13 -0000
From: "William Ottaway" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: DOMSEC anybody?
Date: Tue, 17 Apr 2001 10:49:48 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
In-Reply-To: <003101c0c663$c19dcc60$[e-mail]>
Importance: 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>

Hi Anders,

Comments below.

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Anders Rundgren
> Sent: 16 April 2001 11:54
> To: [e-mail]
> Subject: DOMSEC anybody?
>
>
> Hi
> I think DOMSEC is a very powerful concept but it does not seem to
> be widely adapted
> and the S/MIME-list contains almost no dicussions.
>
> What I wonder if you out there have:
>
> 1. Any working implementions

We have had an implementation built for us. It is intended to have a
commercially available version soon.

>
> 2. A possibility to send me an entire signed DOMSEC-compatible
> S/MIME container

We are currently integrating the module into a messaging solution. Once this
has been achieved we will be able to provide DOMSEC messages.


> Technical questions regarding DOMSEC:
>
> Q1: If an e-mail server is not setup for DOMSEC will the
> end-destination still get
> the message without interoperability problems?

A couple of issues spring to mind.

1) There may be a name mismatch warning due to the subject name in the
certificate being different to the sender of the message. This should not
cause interoperability. I believe that Microsoft no longer do this check.

2) There is a possibility that the innermost signature on a DOMSEC message
will contain no elements in the signerInfos. This is known as an empty
signature. There are some solutions that assume that a signedData with no
elements in the signerInfos only carries a certificate. This will cause a
problem.

Bill

>
> Q2: Are there any TTPs issuing suitable certificates today in the
> same way as they do for Web (domain)-servers?
>
> Q3: Couldn't a single certificate actually serve both of these purposes?
>
> Regards
> Anders Rundgren
> X-OBI
>



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id AAA10065 for ietf-smime-bks; Tue, 17 Apr 2001 00:27:38 -0700 (PDT)
Received: from imail.mff.org (imail.mff.org [206.117.127.135]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA10043 for <[e-mail]>; Tue, 17 Apr 2001 00:27:32 -0700 (PDT)
Received: from plastic1 [65.200.16.2] by imail.mff.org with ESMTP (SMTPD32-6.06) id A985AF00D0; Sat, 14 Apr 2001 08:15:17 -0700
From: "Sam T. Stone" <[e-mail]>
Subject: Your Choice
To: <#field0#>
Date: Sat, 14 Apr 2001 08:06:54 -0700
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE Vdiffondi.1712.3
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0"
Content-Transfer-Encoding: 7bit
Message-Id: <200104140815756.SM00198@plastic1>
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









We will help you get the mortgage
loan you want!&nbsp;

Whether a new home loan is what you seek orto refinance your current home
loan at a lower interest rate and payment, we can help!


Mortgage rates haven't been this low in the last 12 months, take action
now!

Refinance your home with us and include all of those pesky credit card
bills oruse the extra cash for that pool you've always wanted=2E=2E=2E&nbsp=
;


Where others says NO, we say YES!!!

Even if you have been turned down elsewhere, we can help!&nbsp;


Easy terms!
 Our mortgage referral service combines thehighest quality loans with most
economical rates and the easiest
qualification!


Take just 2 minutes to complete our form=2E There is no obligation, all
information is kept strictly confidential, and you must be at least 18
years of age=2E
Service available within the United States only=2E This service is fast and=

free=2E
&nbsp;
CLICK
HERE TO FILL OUT FORM

    &nbsp;
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  

List
 Removal/OPT-OUT Option
 Click
 Here


  




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

<html>

<head>
<title></title>
</head>

<body bgcolor=3D"#FFFFFF" text=3D"#FFFFFF">

<p align=3D"center"><b><font size=3D"5" color=3D"#FF0000">We will help you=
 get the mortgage
loan you want!&nbsp;<br>
</font><font color=3D"#000000"><br>
Whether a new home loan is what you seek or<br>to refinance your current h=
ome loan at a lower interest rate and payment, we can help!<br>
<br>
<font size=3D"4">
Mortgage rates haven't been this low in the last 12 months, take action no=
w!<br>
</font>
Refinance your home with us and include all of those pesky credit card bil=
ls or<br>use the extra cash for that pool you've always wanted=2E=2E=2E&nbs=
p;<br>
<br>
</font><font size=3D"4" color=3D"#0000FF">
Where others says NO, we say YES!!!<br>
</font><font color=3D"#000000">
Even if you have been turned down elsewhere, we can help!&nbsp;<br>
<br>
</font><font color=3D"#0000FF">
Easy terms!</font><font color=3D"#000000">
 Our mortgage referral service combines the<u><br>highest quality loans wi=
th most economical rates and the easiest
qualification</u>!<br>
<br>
</font><font size=3D"4" color=3D"#FF0000">
Take just 2 minutes to complete our form=2E<br></font> </b><font size=3D"2=
" color=3D"#000000"><i>There is no obligation, all information is kept stri=
ctly confidential, and you must be at least 18 years of age=2E<br>
Service available within the United States only=2E This service is fast an=
d free=2E</i></font></p>
<p align=3D"center">&nbsp;</p>
<p align=3D"center"><b><font color=3D"#FF0000" size=3D"5"><a href=3D"http:=
//www=2Emortgageloanfast=2Ecom/">CLICK
HERE TO FILL OUT FORM</a></font></b></p>

    <p align=3D"center">&nbsp;</p>
    <p align=3D"left">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</p>=

  </form>
<p align=3D"center">
<b><font size=3D+1 color=3D"#66cc99">List
 Removal/OPT-OUT Option</font></b>
 <br><b><font color=3D"#000000"><font size=3D-1><a
 href=3D"mailto:xmq31@netscape=2Enet@netscape=2Enet?subject=3Dremove">Clic=
k
 Here</a></font></font></b>


  </body>



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

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





Received: by above.proper.com (8.9.3/8.9.3) id QAA11802 for ietf-smime-bks; Mon, 16 Apr 2001 16:54:19 -0700 (PDT)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by above.proper.com (8.9.3/8.9.3) with SMTP id QAA11797 for <[e-mail]>; Mon, 16 Apr 2001 16:54:18 -0700 (PDT)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.7)); Mon, 16 Apr 2001 16:53:51 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by cane.deming.com with Internet Mail Service (5.5.2650.21) id <H9F0SK08>; Mon, 16 Apr 2001 16:53:51 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Summary of external version number discussion
Date: Mon, 16 Apr 2001 16:53:41 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 16C5598560316-01-01
Content-Type: text/plain;  charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It seems that the contributions so far for the external version number
discussion has yielded either "no comment" or "3.1 is fine with me".  There
seems to have been some confusion that arose from a difference between the
version number stored in the CMS object, and the version number of the
profile (which is not stored anywhere in the CMS object, and is a purely
human convention).

I believe that this is rough consensus (or at least, that's what I'm calling
it until I get into trouble), and the human convention version number will
be 3.1 for the new message and cert profile, in order to differentiate it
from the current version 3 which has a different set of MUST and SHOULD
criteria for algorithms.

Blake
--
Blake C. Ramsdell, Tumbleweed Communications
Voice [phone] x103  Fax [phone]




Received: by above.proper.com (8.9.3/8.9.3) id MAA22702 for ietf-smime-bks; Mon, 16 Apr 2001 12:05:59 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA22697 for <[e-mail]>; Mon, 16 Apr 2001 12:05:58 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <H95FYPV6>; Mon, 16 Apr 2001 15:06:57 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: RE: S/MIME version number
Date: Mon, 16 Apr 2001 15:06:55 -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>

Jim,

I believe that this comment applies to the upcoming CMS draft rather than
the Password Based encryption I-D.

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


-----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Monday, April 16, 2001 3:03 PM
To: 'Pawling, John'; [e-mail]
Subject: RE: S/MIME version number


John,

I think that you need to make a comment about this either in regards to the
Password Base encryption that is currently with the IESG in last call, or
with the upcoming CMS draft to be issued.

jim

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Pawling, John
> Sent: Monday, April 16, 2001 10:26 AM
> To: [e-mail]
> Subject: RE: S/MIME version number
>
>
> Jim,
>
> I believe that when an ASN.1 syntax is changed that includes a version
> field, then a new version number should be assigned to
> indicate the new
> ASN.1 syntax.  If password-based encryption is added as a new
> CHOICE to the
> RecipientInfo syntax (which is part of EnvelopedData), then I
> believe that a
> new version number should be assigned for use in the
> EnvelopedData version
> field.  In that case, I propose that the RFC 2630, Section 6.1
> EnvelopedData Type, version definition should be changed to
> state: "version
> is the syntax version number.  If originatorInfo is present,
> then version
> shall be 3.  If any of the RecipientInfo structures included
> have a version
> other than 0, then version shall be 3.  If unprotectedAttrs
> is present, then
> version shall be 3.  If originatorInfo is absent, all of the
> RecipientInfo
> structures are version 0, and unprotectedAttrs is absent,
> then version shall
> be 0."
>
> ===========================================
> John Pawling, [e-mail]
> Getronics Government Solutions, LLC
> ===========================================
>


Received: by above.proper.com (8.9.3/8.9.3) id MAA22462 for ietf-smime-bks; Mon, 16 Apr 2001 12:00:22 -0700 (PDT)
Received: from femail3.sdc1.sfba.home.com (femail3.sdc1.sfba.home.com [24.0.95.83]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA22450 for <[e-mail]>; Mon, 16 Apr 2001 12:00:20 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail3.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010416185752.CJRY26961.femail3.sdc1.sfba.home.com@revelation>; Mon, 16 Apr 2001 11:57:52 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Pawling, John'" <[e-mail]>, <[e-mail]>
Subject: RE: S/MIME version number
Date: Mon, 16 Apr 2001 12:03:04 -0700
Message-ID: <000901c0c6a7$deb536f0$[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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John,

I think that you need to make a comment about this either in regards to the
Password Base encryption that is currently with the IESG in last call, or
with the upcoming CMS draft to be issued.

jim

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Pawling, John
> Sent: Monday, April 16, 2001 10:26 AM
> To: [e-mail]
> Subject: RE: S/MIME version number
>
>
> Jim,
>
> I believe that when an ASN.1 syntax is changed that includes a version
> field, then a new version number should be assigned to
> indicate the new
> ASN.1 syntax.  If password-based encryption is added as a new
> CHOICE to the
> RecipientInfo syntax (which is part of EnvelopedData), then I
> believe that a
> new version number should be assigned for use in the
> EnvelopedData version
> field.  In that case, I propose that the RFC 2630, Section 6.1
> EnvelopedData Type, version definition should be changed to
> state: "version
> is the syntax version number.  If originatorInfo is present,
> then version
> shall be 3.  If any of the RecipientInfo structures included
> have a version
> other than 0, then version shall be 3.  If unprotectedAttrs
> is present, then
> version shall be 3.  If originatorInfo is absent, all of the
> RecipientInfo
> structures are version 0, and unprotectedAttrs is absent,
> then version shall
> be 0."
>
> ===========================================
> John Pawling, [e-mail]
> Getronics Government Solutions, LLC
> ===========================================
>



Received: by above.proper.com (8.9.3/8.9.3) id KAA17262 for ietf-smime-bks; Mon, 16 Apr 2001 10:25:09 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA17257 for <[e-mail]>; Mon, 16 Apr 2001 10:25:07 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <H95FYNV9>; Mon, 16 Apr 2001 13:26:05 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: RE: S/MIME version number
Date: Mon, 16 Apr 2001 13:26:03 -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>

Jim,

I believe that when an ASN.1 syntax is changed that includes a version
field, then a new version number should be assigned to indicate the new
ASN.1 syntax.  If password-based encryption is added as a new CHOICE to the
RecipientInfo syntax (which is part of EnvelopedData), then I believe that a
new version number should be assigned for use in the EnvelopedData version
field.  In that case, I propose that the RFC 2630, Section 6.1
EnvelopedData Type, version definition should be changed to state: "version
is the syntax version number.  If originatorInfo is present, then version
shall be 3.  If any of the RecipientInfo structures included have a version
other than 0, then version shall be 3.  If unprotectedAttrs is present, then
version shall be 3.  If originatorInfo is absent, all of the RecipientInfo
structures are version 0, and unprotectedAttrs is absent, then version shall
be 0."

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


Received: by above.proper.com (8.9.3/8.9.3) id DAA19144 for ietf-smime-bks; Mon, 16 Apr 2001 03:57:35 -0700 (PDT)
Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA19137 for <[e-mail]>; Mon, 16 Apr 2001 03:57:33 -0700 (PDT)
Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by mailg.telia.com (8.11.2/8.11.0) with ESMTP id f3GAvVH03149 for <[e-mail]>; Mon, 16 Apr 2001 12:57:33 +0200 (CEST)
Received: from mega (t7o69p64.telia.com [213.65.46.64]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id f3GAvTa03204 for <[e-mail]>; Mon, 16 Apr 2001 12:57:29 +0200 (CEST)
Message-ID: <003101c0c663$c19dcc60$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: DOMSEC anybody?
Date: Mon, 16 Apr 2001 12:54:06 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id DAA19140
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi
I think DOMSEC is a very powerful concept but it does not seem to be widely adapted
and the S/MIME-list contains almost no dicussions.

What I wonder if you out there have:

1. Any working implementions

2. A possibility to send me an entire signed DOMSEC-compatible S/MIME container

Technical questions regarding DOMSEC:

Q1: If an e-mail server is not setup for DOMSEC will the end-destination still get
the message without interoperability problems?

Q2: Are there any TTPs issuing suitable certificates today in the same way as they do for Web (domain)-servers?

Q3: Couldn't a single certificate actually serve both of these purposes?

Regards
Anders Rundgren
X-OBI



Received: by above.proper.com (8.9.3/8.9.3) id PAA25484 for ietf-smime-bks; Fri, 13 Apr 2001 15:04:14 -0700 (PDT)
Received: from femail3.sdc1.sfba.home.com (femail3.sdc1.sfba.home.com [24.0.95.83]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA25478 for <[e-mail]>; Fri, 13 Apr 2001 15:04:13 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail3.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010413220146.FHTD13920.femail3.sdc1.sfba.home.com@revelation>; Fri, 13 Apr 2001 15:01:46 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, "'Pawling, John'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: S/MIME version number
Date: Fri, 13 Apr 2001 15:06:46 -0700
Message-ID: <000801c0c466$08c943d0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John,

Where does this argument lead with respect to the addition of more key
managment techniques in an EnvelopedData.  If we add the password based
encryption do you think that we need to up the version number for that?

jim

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Russ Housley
> Sent: Friday, April 13, 2001 1:34 PM
> To: Pawling, John
> Cc: '[e-mail]'
> Subject: RE: S/MIME version number
>
>
> John:
>
> >I respectfully disagree with your statement: "This is
> completely parallel to
> >the public key certificate situation."  The v1, v2 and v3
> X.509 public key
> >certificate syntaxes defined in the 1997 and 2000 X.509
> Recommendations are
> >compatible.  The Attribute Certificate syntaxes defined in
> the 1997 and 2000
> >X.509 Recommendations are incompatible.  The 2000 AC syntax
> can't be used to
> >decode a 1997 AC and vice versa.
>
> I missed your point altogether.  Now I get it.
>
> I spoke with Hoyt about this issue at the RSA Conference.  Someone is
> looking into making them backward compatible.  I am not sure
> how this will
> be sorted out, but I will find out and report back.
>
> Russ
>
>



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA24159 for ietf-smime-bks; Fri, 13 Apr 2001 14:46:46 -0700 (PDT)
Received: from femail3.sdc1.sfba.home.com (femail3.sdc1.sfba.home.com [24.0.95.83]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA24152 for <[e-mail]>; Fri, 13 Apr 2001 14:46:44 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail3.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010413214416.FHDD13920.femail3.sdc1.sfba.home.com@revelation>; Fri, 13 Apr 2001 14:44:16 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>, <"IETF-An"@above.proper.com>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Last Call: Password-based Encryption for S/MIME to Proposed Standard
Date: Fri, 13 Apr 2001 14:47:22 -0700
Message-ID: <000101c0c463$969d46f0$[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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Peter Gutmann
> Sent: Thursday, April 05, 2001 1:36 PM
> To: "IETF-An"@above.proper.com; [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: Last Call: Password-based Encryption for S/MIME
> to Proposed
> Standard
>
>
> "Jim Schaad" <[e-mail]> writes:
>
> >Comments on this draft:
> >
> >[Minor editing odds and ends]
>
> Thanks.  The ASN.1 glitches came about mostly because it was
> originally done in
> '94 and then edited from that back to '88 fairly late, which
> lead to a little
> friction between the two versions.

When you get an updated ASN module(s), please send them to me for futher
verification.
>
> >3. Section 1.2.1: Paragraph 1: The phrase "user-supplied password or
> >previously agreed-upon key" is somewhat misleading.  KEK is
> the generally used
> >agreed-upon key method for key managment.  Please delete the
> phrase "or
> >previously agreed-upon key".  (Ditto for all subsequent references.)
>
> It was originally just "user-supplied password", but then
> people popped up who
> were using it slightly differently, for which "previously
> agreed-upon key"
> fitted perfectly (for example a University in Germany
> somewhere is (or at least
> was when it was written) using it with a PIC wafercard to do
> IDEA wrapping of
> 3DES or DES keys, I thought it was 3DES but thinking back it
> could have been
> just DES, which would imply they're using it for Kerberos
> login... this makes a
> good Uni project since you can fiddle with Kerberos or Sesame
> or whatever using
> cheap, readily-available wafercards).  Anyway, you can't do
> this with CMS-KEK,
> and what they're doing is effectively password-based
> encryption, they're just
> replacing the (Kerberos/Sesame) password with a wafercard,
> thus "previously
> agreed-upon key".

I don't buy this argument anymore than the others, but I think we need to
just say we are going to forever disagree on this and skip it.

>
> >4.  Section 1.2.1: In the event that two password recipient
> info's are
> >present, how do I determine which is the one I am to use?
>
> I'll answer that one in two parts:
>
> 1. What practical need is there for this?  Every
> password-based encryption
>    program from crypt through to this morning's release of
> GPG, asks for a
>    password and then encrypts data with it.  Although it is
> theoretically
>    possible to use multiple passwords, the fact that after
> 20-odd years of
>    password-based encryption utilities noone has seen any
> need to add this
>    indicates that it's not a major issue.

Here is a use for this that I have at present.  There exists a dirth of good
algorithms to use for the AuthenticatedData structure.  At present the only
one that works is Static-Static DH (which is not a standard CMS algorithm).
THe problem is that with algorithms such as RSA and E-S DH there is no
method of authenticating the originator.  I could use the password protected
key for doing AuthenticatedData. (Thus proving that it originated with
somebody who could correctly compute the password.)  If I use it in this
senerio then I need some way for a server to determine which of the many
recipients originated this message and thus what password based key is
needed for validating of the AuthenticatedData structure.

>
> 2. How would you add support for this?  That is, how do you
> identify in the
>    PWRI which password is being used?  The usual method -
> throw in an OCTET
>    STRING hole and let people dump whatever they want in it -
> isn't much use
>    because every implementor will choose something different,
> which means app A
>    won't be able to do anything useful with a PWRI from app B.
>
> The reason there's no provision for handling more than one PWRI is a
> combination of the two above points, there doesn't seem to be
> any real demand
> for it, and without real-world requirements it's not possible
> to determine what
> should be done.  If a real-world demand does emerge in a
> years time (or
> whenever), we can publish a v2 which addresses it, but trying
> to guess in
> advance a solution to an unknown problem seems risky.
>
> (Having said that, if you know of a good solution to this
> problem which doesn't
>  involve OCTET STRING holes or a SEQUENCE OF
> everything-imaginable OPTIONAL
>  (which is about the same thing) I'd love to hear it, if
> there really is a
>  clear, precise solution I'll be happy to add it).

You might not like octet holes, I might not octet holes (possibly for
different reasons) but they provide the simpliest solition to this problem.
I would suggest that the same identification structure is used for this as
is currently used for KEKRecipientInfo.  This is fairly general purpose.

>
> >6.  Section 1.2.1: Paragraph keyDerivationAlgorithm: Please
> justfy why this is
> >optional.
>
> See (3) above.

see (3) above.

>
> >8.  Section 2.2 & 2.3:  You have Key Encryption algorithms
> and Symmetric Key
> >Encryption algorithms.  I don't understand the difference
> between these two
> >groups as they both appear to be using symmetric keys, take
> a KEK and encrypt
> >a CEK.  The only difference appears to be that the first are
> simple encrytion
> >algorithms and the second are complex ones.
>
> They're both completely standard, off-the-shelf algorithms
> (eg DES-CBC, 3DES-
> CBC, whatever).  The only reason they're distinguished in the
> text is to allow
> a description of the difference between a KEK and CEK, and
> because the KEK
> algorithms (section 2.2) are tied to RFC 2898 while the CEK
> ones (section 2.3)
> aren't.  Putting them in the same section would make it
> rather confusing, or at
> least less unambiguous.

While I could by that argument, section 2.3 is talking about Symetric KEY
encryption algorithms not CONTENT encryption algorithms.  Again what is the
difference between the two sections.

>
> >10. Section 2.2:  Why is Triple-DES/CBC a MUST algorithm.
> This appears to be
> >reasonable for content encryption but is not a good idea for
> key encryption.
>
> To guarantee interoperability?  You need at least one MUST,
> and 3DES seems to
> be the most widely-accepted algorithm.  Why would you not
> have a standard
> algorithm as a MUST?
>
> >12.  Section 2.3.3: unwrap Item 2:  This does not appear to
> agree with the
> >algorithm in section 2.3.2.  Should it not be "Set the IV to
> the decrypted
> >content, decrypt the first 8 bytes."?
>
> No, it's correct as it stands (because encryption is just two
> passes of
> straight encryption, the IV for the outer encrypted layer is
> the last block of
> the inner encrypted layer).  A number of people have created
> implementations
> from that text without any problems.
>
> >13.  Section 2.2: I am having a problem with what you are
> using for the
> >KeyEncryptionAlgorithm.  I think that you need to use
> something other than the
> >standard content-encryption algorithm OIDs in this location
> due to the fact
> >that you are adding additional processing in the form of the wrapping
> >algorithm.  I think that this issue alone is a killer for
> this document as it
> >is presently set out.
>
> I'm sorry, but I don't understand this comment.  One of the
> design goals of the
> PWRI wrapping is that it uses completely standard algorithms
> and modes without
> any need to invent new OIDs, encryption modes, mechanisms, or
> whatnot (you can
> take any standard block cipher off the shelf with a standard
> OID and use it to
> wrap the key).  What you're saying is that you want a series
> of gratuitously
> incompatible OIDs used in order to make implementation
> difficult?  This would
> lead to complete chaos, every time a new algorithm turns up
> you'd need to
> either update the existing RFC or publish a new one just to
> define a new,
> incompatible OID... it'd be a nightmare for implementors,
> you'd have to do a
> new code release every month or so just to keep up with all
> the new OIDs you're
> defininig, even though you're using completely standard
> algorithms.  In
> contrast the current approach fits right in with any existing
> algorithm/OID
> (for example although it was published long before AES came out, it's
> automatically compatible with AES without having to publish a
> new RFC just to
> define an AES-wrap OID).

What you want and what I want are not incompatable.  If you defined an
id-alg-pwri-kek-encryption OID, gave it the structure of AlgorithmIdentifier
then you and I could both be happy. I would have a seperate OID to
distingish between a KEK and a CEK algorithm (ie-alg-pwri-kek-encryption vs
des-3DES-CBC) and you would not need to define a new OID for every algorithm
under the sun.  The content encryption algorithm is the parameter to the key
wrap algorithm.  I cannot accept that des-3DES-CBC is a different algorithm
based soley on the location in the ASN that the OID is placed.

>
> >14.  Section 2.2: It is still my belief that the key wrap
> algorithm presented
> >as part of RFC2460 should be the MUST key wrap algorithm
> (i.e. id-alg-
> >CMS3DESwrap).  The CMS version will be implemented in
> software for CMS
> >compatilibity and in all likely hood will also be done in
> hardware as well if
> >KEK encryption ever becomes real common place. (For use with
> S/MIME symmetric
> >key mailing lists if nothing else.) While I don't object to
> your offering a
> >second key wrap algorithm I don't see a strong benifit for
> it over the already
> >existing version in CMS.
>
> The PWRI algorithm is a one-size-fits-all mechanism which
> works with any
> cipher, including ones not yet invented (an example being
> AES, at the time the
> draft was first written).  At the time of writing, the CMS
> KEK wrap only worked
> for 3DES-in-3DES wrap and RC2-in-RC2 wrap, and nothing else.
> In contrast the
> PWRI wrap works for any algorithm, so you only have to
> implement the mechanism
> once and it'll work for every future algorithm.  CMS KEK wrap
> has since been
> extended via a string of extra RFCs to handle IDEA-in-IDEA
> wrap and CAST128-in-
> CAST128 wrap, but it still doesn't handle anything else (for
> example it won't
> handle the 3DES-in-IDEA or DES-in-IDEA wrap mentioned in (3)
> above, and it's
> going to require yet another new RFC to handle AES).
>
> While it would be possible to change the text to say
> something like "Use this
> mechanism for everything but 3DES", all that'll do is lead to
> unnecessary
> complexity and interop problems (not to mention thoughts of
> "What the..." from
> anyone who's seeing that requirement for the first time :-).
>
> In terms of hardware implementation, I haven't seen PKCS #11
> vendors rushing to
> implement CMS KEK.  OTOH since the PWRI wrap works with any
> standard cipher
> with no special processing required, it's automatically
> supported in hardware
> already.

I have no method of verifying or disproving you statement at that it is
already in hardware, but I find it difficult to believe that id does not
require additional software above the hardware level to implement.  That
being the case I can make the exact same argument for the CMS key wrap, that
a software module operating above a standard card implementing the standard
content encryption algorithm can be used to implement CMS.  That in fact is
actually the first way that I impemented the CMS key wrap algorithm for test
purposes.

>
> Overall, the current draft just plain works, I don't see why
> it needs to be
> artificially restricted or use incompatible OIDs whose only
> purpose seems to be
> to make implementation a pain.
>
> Peter.
>
> (I'm heading out for the RSA conference tomorrow so it may
> take me awhile to
>  reply to followups).
>
>



jim



Received: by above.proper.com (8.9.3/8.9.3) id NAA18508 for ietf-smime-bks; Fri, 13 Apr 2001 13:42:43 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id NAA18504 for <[e-mail]>; Fri, 13 Apr 2001 13:42:39 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 13 Apr 2001 20:40:06 UT
Received: from HOUSLEY-LAP.rsasecurity.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA11464; Fri, 13 Apr 2001 16:42:40 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 13 Apr 2001 16:34:12 -0400
To: "Pawling, John" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: S/MIME version number
Cc: "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John:

>I respectfully disagree with your statement: "This is completely parallel to
>the public key certificate situation."  The v1, v2 and v3 X.509 public key
>certificate syntaxes defined in the 1997 and 2000 X.509 Recommendations are
>compatible.  The Attribute Certificate syntaxes defined in the 1997 and 2000
>X.509 Recommendations are incompatible.  The 2000 AC syntax can't be used to
>decode a 1997 AC and vice versa.

I missed your point altogether.  Now I get it.

I spoke with Hoyt about this issue at the RSA Conference.  Someone is 
looking into making them backward compatible.  I am not sure how this will 
be sorted out, but I will find out and report back.

Russ



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA15784 for ietf-smime-bks; Fri, 13 Apr 2001 12:57:19 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA15779 for <[e-mail]>; Fri, 13 Apr 2001 12:57:17 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <H95FYCNN>; Fri, 13 Apr 2001 15:58:17 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: S/MIME version number
Date: Fri, 13 Apr 2001 15:58:15 -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>

Russ,

I respectfully disagree with your statement: "This is completely parallel to
the public key certificate situation."  The v1, v2 and v3 X.509 public key
certificate syntaxes defined in the 1997 and 2000 X.509 Recommendations are
compatible.  The Attribute Certificate syntaxes defined in the 1997 and 2000
X.509 Recommendations are incompatible.  The 2000 AC syntax can't be used to
decode a 1997 AC and vice versa.

If a v4 public key certificate is defined that is backwards compatible with
the v1, v2 and v3 X.509 public key certificate syntaxes defined in the 1997
and 2000 X.509 Recommendations, then I agree that the signedData and
EnvelopedData version numbers would not need to be changed to reflect the
inclusion of a v4 cert.

I agree that there are work-arounds for this problem, but I prefer that we
define a clean strategy (i.e. new SignedData and EnvelopedData version
numbers), rather than needing to resort to work-arounds.

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


-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Friday, April 13, 2001 2:15 PM
To: Pawling, John
Cc: '[e-mail]'
Subject: RE: S/MIME version number


John:

I am missing something.

Let's take SignedData as an example:

       SignedData ::= SEQUENCE {
         version CMSVersion,
         digestAlgorithms DigestAlgorithmIdentifiers,
         encapContentInfo EncapsulatedContentInfo,
         certificates [0] IMPLICIT CertificateSet OPTIONAL,
         crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,
         signerInfos SignerInfos }

The optional certificates field can contain certificates or attribute 
certificates.  We deprecate the use of PKCS #6 extended certificates.  As 
follows:

       CertificateSet ::= SET OF CertificateChoices

       CertificateChoices ::= CHOICE {
          certificate Certificate,                 -- See X.509
          extendedCertificate [0] IMPLICIT ExtendedCertificate,
                                                   -- Obsolete
          attrCert [1] IMPLICIT AttributeCertificate }
                                                   -- See X.509 and X9.57

The certificate choice can be a v1, v2, or v3 X.509 public key 
certificate.  One must examine the version field within the certificate to 
determine the format.

At the time RFC 2630 was written, only v1 attribute certificates were 
defined.  Now that v2 attribute certificates have been defined, one must 
examine the version field to determine the format.  This is completely 
parallel to the public key certificate situation.

I am missing the reason that you think that the version number in 
SignedData needs to reflect the possibility that v2 attribute 
certificate.  If a v4 public key certificate were to be defined (hopefully 
it will not be needed), I would not expect to increment the version number 
either.

Now, to the toolkit issue.

I realize that implementation would be more straightforward if the version 
number proceeded an OCTET STRING or an ANY.  But neither public key 
certificates, attribute certificate, nor PKCS #7 were specified that 
way.  However, there are several implementations techniques that allow 
correct handling.  I will describe two.  There are many more.

First, two-pass decode.  In this alternative, a very ASN.1 simple structure 
is specified to extract the version.  Consider the SignedData syntax 
included above. The structure might look like this:

       SignedDataVersionCheck ::= SEQUENCE {
         version CMSVersion,
         theRest ANY }

While this might generate a warning that extra fields are present, it 
should return the version number.  The version can be examined to determine 
whether or not the provided version is supported.

Second, check if decode fails.  In this alternative, just try the 
decode.  If it fails, then examine version numbers (perhaps using the 
technique discussed above) to determine if the blob is malformed or it uses 
unsupported versions.

I prefer this approach to the first one because the extra decode operations 
are only performed if there is a problem.  Thus, successful messages are 
not encumbered with the extra processing.  Optimize for success.

What do other implementors think?

Russ



At 10:52 AM 4/13/2001 -0400, Pawling, John wrote:
>Russ,
>
>The AC syntax is an integral part of the SignedData and EnvelopedData
>syntaxes, so the SignedData and EnvelopedData version numbers should be
>changed to indicate the new syntaxes.  Many generic ASN.1 toolkits (such as
>SNACC) decode the entire syntax in one pass (except for data included
within
>ANY or OCTET STRING components which require a second pass).  There is not
a
>straight forward means of changing the generic ASN.1 toolkit to check
>version numbers "mid-stream" while decoding the syntax.  Because the AC
>syntax is not included in an ANY or OCTET STRING component, it is not
>practical to check the AC version number before decoding the AC using a
>generic ASN.1 toolkit.
>
>My proposal would allow implementers to perform a simple pre-check of the
>signedData or EnvelopedData hex data before calling the generic ASN.1
>toolkit to decode the hex data.  There is a fixed number of bytes preceding
>the version number in the ASN.1 encoded SignedData and EnvelopedData hex
>data, so the processing software could simply check the fixed byte position
>to determine the version number.  For signedData, if the version number is
>3, then the processing software would call the ASN.1 library using the
>signedData syntax including the old AC syntax.  If the version number is 4,
>then the processing software would call the ASN.1 library using the
>signedData syntax including the new AC syntax.  Similar pre-processing
could
>be performed for EnvelopedData objects.
>
>Of course another option is to simply use trial and error.  We could try
>decoding the SignedData or EnvelopedData using the syntax including the new
>AC syntax.  If we get a decode error, then we could try using the syntax
>containing the old AC syntax.  I would prefer that we define a clean
>strategy (i.e. new SignedData and EnvelopedData version numbers), rather
>than needing to resort to trial and error.
>
>I people prefer that the S/MIME documents import ASN.1 structures from the
>PKIX documents because they are freely available.  Care needs to be taken
>that the PKIX documents define equivalent ASN.1 syntaxes as the ITU-T
>documents and ANSI X9 documents, assuming that interoperability is
required.
>As expressed in previous messages sent to the S/MIME and PKIX lists, the
>current PKIX AC profile document defines an AC syntax that is not
equivalent
>to the v2 AC syntax defined in the 2000 X.509 Recommendation.
>
>===========================================
>John Pawling, [e-mail]
>Getronics Government Solutions, LLC
>===========================================
>
>
>-----Original Message-----
>From: Russ Housley [mailto:[e-mail]]
>Sent: Thursday, April 12, 2001 1:45 PM
>To: Pawling, John
>Cc: '[e-mail]'
>Subject: RE: S/MIME version number
>
>
>John:
>
>I understand that X.509-2000 includes updated syntax for the attribute
>Certificate (AC).  However, this structure already includes a version
>number.  The earlier syntax has v1, and the later syntax has v2.  Since
>this stricture is "self versioning," why do we need to update the version
>number in the parent structure?
>
>Would people prefer to import structures from the PKIX documents (as
>opposed to the ITU-T and ANSI X9 documents)?  At the time RFC 2630 was
>done, PKIX did not have a profile of ACs.  Note that the PKIX AC profile
>requires the use of v2 AC syntax.
>
>Russ
>
>At 10:51 AM 4/9/2001 -0400, Pawling, John wrote:
> >However, there is another factor to discuss related to this issue.  The
> >Attribute Certificate (AC) ASN.1 syntaxes defined in the 1997 and 2000
>X.509
> >Recommendations are incompatible.  I believe that it is planned for the
> >"son-of-RFC 2630" to import the AC syntax from the 2000 X.509
>Recommendation
> >rather than from the 1997 X.509 Recommendation as with RFC 2630.  This
will
> >result in a change to the AC syntax included in the CertificateChoices
> >syntax used in the CMS SignedData and EnvelopedData syntaxes.


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA13195 for ietf-smime-bks; Fri, 13 Apr 2001 12:36:46 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA13187 for <[e-mail]>; Fri, 13 Apr 2001 12:36:44 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 13 Apr 2001 19:34:11 UT
Received: from HOUSLEY-LAP.rsasecurity.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA22545; Fri, 13 Apr 2001 15:36:30 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 13 Apr 2001 14:14:30 -0400
To: "Pawling, John" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: S/MIME version number
Cc: "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John:

I am missing something.

Let's take SignedData as an example:

       SignedData ::= SEQUENCE {
         version CMSVersion,
         digestAlgorithms DigestAlgorithmIdentifiers,
         encapContentInfo EncapsulatedContentInfo,
         certificates [0] IMPLICIT CertificateSet OPTIONAL,
         crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,
         signerInfos SignerInfos }

The optional certificates field can contain certificates or attribute 
certificates.  We deprecate the use of PKCS #6 extended certificates.  As 
follows:

       CertificateSet ::= SET OF CertificateChoices

       CertificateChoices ::= CHOICE {
          certificate Certificate,                 -- See X.509
          extendedCertificate [0] IMPLICIT ExtendedCertificate,
                                                   -- Obsolete
          attrCert [1] IMPLICIT AttributeCertificate }
                                                   -- See X.509 and X9.57

The certificate choice can be a v1, v2, or v3 X.509 public key 
certificate.  One must examine the version field within the certificate to 
determine the format.

At the time RFC 2630 was written, only v1 attribute certificates were 
defined.  Now that v2 attribute certificates have been defined, one must 
examine the version field to determine the format.  This is completely 
parallel to the public key certificate situation.

I am missing the reason that you think that the version number in 
SignedData needs to reflect the possibility that v2 attribute 
certificate.  If a v4 public key certificate were to be defined (hopefully 
it will not be needed), I would not expect to increment the version number 
either.

Now, to the toolkit issue.

I realize that implementation would be more straightforward if the version 
number proceeded an OCTET STRING or an ANY.  But neither public key 
certificates, attribute certificate, nor PKCS #7 were specified that 
way.  However, there are several implementations techniques that allow 
correct handling.  I will describe two.  There are many more.

First, two-pass decode.  In this alternative, a very ASN.1 simple structure 
is specified to extract the version.  Consider the SignedData syntax 
included above. The structure might look like this:

       SignedDataVersionCheck ::= SEQUENCE {
         version CMSVersion,
         theRest ANY }

While this might generate a warning that extra fields are present, it 
should return the version number.  The version can be examined to determine 
whether or not the provided version is supported.

Second, check if decode fails.  In this alternative, just try the 
decode.  If it fails, then examine version numbers (perhaps using the 
technique discussed above) to determine if the blob is malformed or it uses 
unsupported versions.

I prefer this approach to the first one because the extra decode operations 
are only performed if there is a problem.  Thus, successful messages are 
not encumbered with the extra processing.  Optimize for success.

What do other implementors think?

Russ



At 10:52 AM 4/13/2001 -0400, Pawling, John wrote:
>Russ,
>
>The AC syntax is an integral part of the SignedData and EnvelopedData
>syntaxes, so the SignedData and EnvelopedData version numbers should be
>changed to indicate the new syntaxes.  Many generic ASN.1 toolkits (such as
>SNACC) decode the entire syntax in one pass (except for data included within
>ANY or OCTET STRING components which require a second pass).  There is not a
>straight forward means of changing the generic ASN.1 toolkit to check
>version numbers "mid-stream" while decoding the syntax.  Because the AC
>syntax is not included in an ANY or OCTET STRING component, it is not
>practical to check the AC version number before decoding the AC using a
>generic ASN.1 toolkit.
>
>My proposal would allow implementers to perform a simple pre-check of the
>signedData or EnvelopedData hex data before calling the generic ASN.1
>toolkit to decode the hex data.  There is a fixed number of bytes preceding
>the version number in the ASN.1 encoded SignedData and EnvelopedData hex
>data, so the processing software could simply check the fixed byte position
>to determine the version number.  For signedData, if the version number is
>3, then the processing software would call the ASN.1 library using the
>signedData syntax including the old AC syntax.  If the version number is 4,
>then the processing software would call the ASN.1 library using the
>signedData syntax including the new AC syntax.  Similar pre-processing could
>be performed for EnvelopedData objects.
>
>Of course another option is to simply use trial and error.  We could try
>decoding the SignedData or EnvelopedData using the syntax including the new
>AC syntax.  If we get a decode error, then we could try using the syntax
>containing the old AC syntax.  I would prefer that we define a clean
>strategy (i.e. new SignedData and EnvelopedData version numbers), rather
>than needing to resort to trial and error.
>
>I people prefer that the S/MIME documents import ASN.1 structures from the
>PKIX documents because they are freely available.  Care needs to be taken
>that the PKIX documents define equivalent ASN.1 syntaxes as the ITU-T
>documents and ANSI X9 documents, assuming that interoperability is required.
>As expressed in previous messages sent to the S/MIME and PKIX lists, the
>current PKIX AC profile document defines an AC syntax that is not equivalent
>to the v2 AC syntax defined in the 2000 X.509 Recommendation.
>
>===========================================
>John Pawling, [e-mail]
>Getronics Government Solutions, LLC
>===========================================
>
>
>-----Original Message-----
>From: Russ Housley [mailto:[e-mail]]
>Sent: Thursday, April 12, 2001 1:45 PM
>To: Pawling, John
>Cc: '[e-mail]'
>Subject: RE: S/MIME version number
>
>
>John:
>
>I understand that X.509-2000 includes updated syntax for the attribute
>Certificate (AC).  However, this structure already includes a version
>number.  The earlier syntax has v1, and the later syntax has v2.  Since
>this stricture is "self versioning," why do we need to update the version
>number in the parent structure?
>
>Would people prefer to import structures from the PKIX documents (as
>opposed to the ITU-T and ANSI X9 documents)?  At the time RFC 2630 was
>done, PKIX did not have a profile of ACs.  Note that the PKIX AC profile
>requires the use of v2 AC syntax.
>
>Russ
>
>At 10:51 AM 4/9/2001 -0400, Pawling, John wrote:
> >However, there is another factor to discuss related to this issue.  The
> >Attribute Certificate (AC) ASN.1 syntaxes defined in the 1997 and 2000
>X.509
> >Recommendations are incompatible.  I believe that it is planned for the
> >"son-of-RFC 2630" to import the AC syntax from the 2000 X.509
>Recommendation
> >rather than from the 1997 X.509 Recommendation as with RFC 2630.  This will
> >result in a change to the AC syntax included in the CertificateChoices
> >syntax used in the CMS SignedData and EnvelopedData syntaxes.



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA24946 for ietf-smime-bks; Fri, 13 Apr 2001 07:51:17 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA24939 for <[e-mail]>; Fri, 13 Apr 2001 07:51:15 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <H95FX00S>; Fri, 13 Apr 2001 10:52:13 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: S/MIME version number
Date: Fri, 13 Apr 2001 10:52:11 -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>

Russ,

The AC syntax is an integral part of the SignedData and EnvelopedData
syntaxes, so the SignedData and EnvelopedData version numbers should be
changed to indicate the new syntaxes.  Many generic ASN.1 toolkits (such as
SNACC) decode the entire syntax in one pass (except for data included within
ANY or OCTET STRING components which require a second pass).  There is not a
straight forward means of changing the generic ASN.1 toolkit to check
version numbers "mid-stream" while decoding the syntax.  Because the AC
syntax is not included in an ANY or OCTET STRING component, it is not
practical to check the AC version number before decoding the AC using a
generic ASN.1 toolkit.  

My proposal would allow implementers to perform a simple pre-check of the
signedData or EnvelopedData hex data before calling the generic ASN.1
toolkit to decode the hex data.  There is a fixed number of bytes preceding
the version number in the ASN.1 encoded SignedData and EnvelopedData hex
data, so the processing software could simply check the fixed byte position
to determine the version number.  For signedData, if the version number is
3, then the processing software would call the ASN.1 library using the
signedData syntax including the old AC syntax.  If the version number is 4,
then the processing software would call the ASN.1 library using the
signedData syntax including the new AC syntax.  Similar pre-processing could
be performed for EnvelopedData objects. 

Of course another option is to simply use trial and error.  We could try
decoding the SignedData or EnvelopedData using the syntax including the new
AC syntax.  If we get a decode error, then we could try using the syntax
containing the old AC syntax.  I would prefer that we define a clean
strategy (i.e. new SignedData and EnvelopedData version numbers), rather
than needing to resort to trial and error.

I people prefer that the S/MIME documents import ASN.1 structures from the
PKIX documents because they are freely available.  Care needs to be taken
that the PKIX documents define equivalent ASN.1 syntaxes as the ITU-T
documents and ANSI X9 documents, assuming that interoperability is required.
As expressed in previous messages sent to the S/MIME and PKIX lists, the
current PKIX AC profile document defines an AC syntax that is not equivalent
to the v2 AC syntax defined in the 2000 X.509 Recommendation.  

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


-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Thursday, April 12, 2001 1:45 PM
To: Pawling, John
Cc: '[e-mail]'
Subject: RE: S/MIME version number


John:

I understand that X.509-2000 includes updated syntax for the attribute 
Certificate (AC).  However, this structure already includes a version 
number.  The earlier syntax has v1, and the later syntax has v2.  Since 
this stricture is "self versioning," why do we need to update the version 
number in the parent structure?

Would people prefer to import structures from the PKIX documents (as 
opposed to the ITU-T and ANSI X9 documents)?  At the time RFC 2630 was 
done, PKIX did not have a profile of ACs.  Note that the PKIX AC profile 
requires the use of v2 AC syntax.

Russ

At 10:51 AM 4/9/2001 -0400, Pawling, John wrote:
>However, there is another factor to discuss related to this issue.  The
>Attribute Certificate (AC) ASN.1 syntaxes defined in the 1997 and 2000
X.509
>Recommendations are incompatible.  I believe that it is planned for the
>"son-of-RFC 2630" to import the AC syntax from the 2000 X.509
Recommendation
>rather than from the 1997 X.509 Recommendation as with RFC 2630.  This will
>result in a change to the AC syntax included in the CertificateChoices
>syntax used in the CMS SignedData and EnvelopedData syntaxes.


Received: by above.proper.com (8.9.3/8.9.3) id GAA18702 for ietf-smime-bks; Fri, 13 Apr 2001 06:37:26 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id GAA18693 for <[e-mail]>; Fri, 13 Apr 2001 06:37:24 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 13 Apr 2001 13:34:50 UT
Received: from HOUSLEY-LAP.rsasecurity.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA01010; Fri, 13 Apr 2001 09:37:13 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 12 Apr 2001 13:45:13 -0400
To: "Pawling, John" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: S/MIME version number
Cc: "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John:

I understand that X.509-2000 includes updated syntax for the attribute 
Certificate (AC).  However, this structure already includes a version 
number.  The earlier syntax has v1, and the later syntax has v2.  Since 
this stricture is "self versioning," why do we need to update the version 
number in the parent structure?

Would people prefer to import structures from the PKIX documents (as 
opposed to the ITU-T and ANSI X9 documents)?  At the time RFC 2630 was 
done, PKIX did not have a profile of ACs.  Note that the PKIX AC profile 
requires the use of v2 AC syntax.

Russ

At 10:51 AM 4/9/2001 -0400, Pawling, John wrote:
>However, there is another factor to discuss related to this issue.  The
>Attribute Certificate (AC) ASN.1 syntaxes defined in the 1997 and 2000 X.509
>Recommendations are incompatible.  I believe that it is planned for the
>"son-of-RFC 2630" to import the AC syntax from the 2000 X.509 Recommendation
>rather than from the 1997 X.509 Recommendation as with RFC 2630.  This will
>result in a change to the AC syntax included in the CertificateChoices
>syntax used in the CMS SignedData and EnvelopedData syntaxes.



Received: by above.proper.com (8.9.3/8.9.3) id MAA01218 for ietf-smime-bks; Thu, 12 Apr 2001 12:50:56 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA01210 for <[e-mail]>; Thu, 12 Apr 2001 12:50:54 -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 PAA08995; Thu, 12 Apr 2001 15:50:50 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>, IANA <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>
Cc: [e-mail]
From: The IESG <[e-mail]>
Subject: Document Action: Implementing Company Classification Policy with the S/MIME Security Label to Informational
Date: Thu, 12 Apr 2001 15:50:50 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the Internet-Draft 'Implementing Company
Classification Policy with the S/MIME Security Label'
<draft-ietf-smime-seclabel-03.txt> as an Informational RFC.
This document is the product of the S/MIME Mail Security Working
Group.  The IESG contact persons are Jeffrey Schiller and Marcus Leech.


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id BAA10165 for ietf-smime-bks; Thu, 12 Apr 2001 01:37:13 -0700 (PDT)
Received: from mailf.telia.com (mailf.telia.com [194.22.194.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA10156 for <[e-mail]>; Thu, 12 Apr 2001 01:37:10 -0700 (PDT)
Received: from Hydra.x-obi.com ([212.181.94.147]) by mailf.telia.com (8.11.2/8.11.0) with ESMTP id f3C8b9X13982 for <[e-mail]>; Thu, 12 Apr 2001 10:37:09 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Thu, 12 Apr 2001 10:35:59 +0200
To: [e-mail]
From: Peter Tornberg <[e-mail]>
Subject: multipart/signed interoperability
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_268233950==_"
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>

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

Hi all,

Thanks for all responses regarding my multipart/signed questions. Some of 
the problems I encountered were problems related to our own PKCS7 module.

Still I have found some interoperability problems when signing/verifying 
MIME multipart bodies. Attached are four different S/MIME messages. The two 
files ending in _fail could not be verified by openssl. These two files are 
the two non _fail files modified with an extra CRLF added (see below). 
However both _fail files could be verified by Outlook Express 5.0.

The two files starting with signed... were created by OE while the ones 
named openssl... were created by (surprise!) openssl.

My conclusions are the following:

OE verifies:
----------------------------------------
Content-Type multipart/signed boundary=outer

--outer
Content-Type: multipart/something 
boundary=inner                  //Signature starts on C
...
--inner
Content-Type: text/plain
...
--inner
Content-Type: text/html
...
--inner--
<CRLF>                               //Signature stops on first CRLF after 
ending inner boundary
<CRLF>
<CRLF>
<CRLF>
--outer
...



Openssl verifies:
-----------------------------------------
Content-Type multipart/signed boundary=outer

--outer
Content-Type: multipart/something 
boundary=inner                   //Signature starts on C
...
--inner
Content-Type: text/plain
...
--inner
Content-Type: text/html
...
--inner--
<CRLF>
<CRLF>
<CRLF>             //Signature stops at the second to last CRLF before the 
outer boundary.
<CRLF>
--outer
...

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

When seperating the inner multipart and the outer boundary with TWO 
boundarys, OE and Openssl will verify the same data. Else one of them will 
fail depending on who signed the data.

Signing and verifying a simple Mime body is interoperable.

/Peter
--=====================_268233950==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="signed_multi.eml"

Return-Path: <[e-mail]>
Received: from mailf.telia.com (mailf.telia.com [194.22.194.25])
	by d1o3.telia.com (8.10.2/8.10.1) with ESMTP id f3C7QoW16124
	for <[e-mail]>; Thu, 12 Apr 2001 09:26:50 +0200 (CEST)
Received: from Hydra ([212.181.94.147])
	by mailf.telia.com (8.11.2/8.11.0) with SMTP id f3C7QoX13657
	for <[e-mail]>; Thu, 12 Apr 2001 09:26:50 +0200 (CEST)
Message-ID: <000b01c0c321$c731f150$0b00a8c0@Hydra>
From: "Peter Tornberg" <[e-mail]>
To: "Peter Tornberg" <[e-mail]>
Subject: signed multi
Date: Thu, 12 Apr 2001 09:25:39 +0200
MIME-Version: 1.0
Content-Type: multipart/signed;
	protocol="application/x-pkcs7-signature";
	micalg=SHA1;
	boundary="----=_NextPart_000_0005_01C0C332.89EF8210"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Status:   

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01C0C332.89EF8210
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0006_01C0C332.89EF8210"


------=_NextPart_001_0006_01C0C332.89EF8210
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

kakak baka =E5ka =E4lg

------=_NextPart_001_0006_01C0C332.89EF8210
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>kakak baka =E5ka =
=E4lg</FONT></DIV></BODY></HTML>

------=_NextPart_001_0006_01C0C332.89EF8210--

------=_NextPart_000_0005_01C0C332.89EF8210
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFvjCCAnUw
ggHeoAMCAQICEC7jDupHUnOxTRlOQ4Ijwd8wDQYJKoZIhvcNAQEFBQAwHjELMAkGA1UEBhMCVVMx
DzANBgNVBAMTBlgtU2lnbjAeFw0wMDEyMDYxNTQwMTBaFw0wMjEyMDYxNTQ4MzZaMB4xCzAJBgNV
BAYTAlVTMQ8wDQYDVQQDEwZYLVNpZ24wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANOJcoMv
9wYdteb4oK1GTaKUwBdnm1ew26T2zw9wNG8O342DPTzgPK+mnZurEZZMk/fVzR6a025V0FIcpxNn
e72Mv2kKaeksMBTD2g6aSazSf9kitTNANBXOBXYkExu44dfbW3f7fIkKpz3NqaPWjl8ELhmvL56t
lS9y1JF/VAMTAgMBAAGjgbMwgbAwCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0O
BBYEFEKbvg1oYXw9q9mHK+zSF1IEi4KZMF8GA1UdHwRYMFYwKKAmoCSGImh0dHA6Ly9oeWRyYS9D
ZXJ0RW5yb2xsL1gtU2lnbi5jcmwwKqAooCaGJGZpbGU6Ly9cXEh5ZHJhXENlcnRFbnJvbGxcWC1T
aWduLmNybDAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG9w0BAQUFAAOBgQCcmlT2aFelHdU6Rree
xQy798iGl5UKp3hxDLQuUUU/s7CzT0eTjEbL7X3cr9Lt9+fFiMo/tiofxMmq+s6RUyo1SN8acBZL
fSjPYyBh+BcqjXX4L+BTZWCtmLqFrfc+Fkx3X1CU1YykruWF/7c92EW54jCWBFBwACoLtHB2hJVf
eTCCA0EwggKqoAMCAQICCgEFGWwAAAAAABQwDQYJKoZIhvcNAQEFBQAwHjELMAkGA1UEBhMCVVMx
DzANBgNVBAMTBlgtU2lnbjAeFw0wMTAzMjIxMjA1NTFaFw0wMjAzMjIxMjE1NTFaMGgxHjAcBgkq
hkiG9w0BCQEWD3RiZXJnQHgtb2JpLmNvbTELMAkGA1UEBhMCU0UxEDAOBgNVBAcTB1VwcHNhbGEx
DjAMBgNVBAoTBVgtT0JJMRcwFQYDVQQDEw5QZXRlciBUb3JuYmVyZzBcMA0GCSqGSIb3DQEBAQUA
A0sAMEgCQQCw15h3MVA9+ljEdjh2Bn/kpy8XStO7Pood46wWUcqtm1uxZ1BP9waZgGUBDDGAlEBI
iGVYQ/97oSXUWyM6d0MPAgMBAAGjggF+MIIBejAOBgNVHQ8BAf8EBAMCBPAwEwYDVR0lBAwwCgYI
KwYBBQUHAwQwHQYDVR0OBBYEFEvvbiPRcnXMuprTKleJlKMlIEvlMFUGA1UdIwROMEyAFEKbvg1o
YXw9q9mHK+zSF1IEi4KZoSKkIDAeMQswCQYDVQQGEwJVUzEPMA0GA1UEAxMGWC1TaWdughAu4w7q
R1JzsU0ZTkOCI8HfMF8GA1UdHwRYMFYwKKAmoCSGImh0dHA6Ly9oeWRyYS9DZXJ0RW5yb2xsL1gt
U2lnbi5jcmwwKqAooCaGJGZpbGU6Ly9cXEh5ZHJhXENlcnRFbnJvbGxcWC1TaWduLmNybDB8Bggr
BgEFBQcBAQRwMG4wNAYIKwYBBQUHMAKGKGh0dHA6Ly9oeWRyYS9DZXJ0RW5yb2xsL0h5ZHJhX1gt
U2lnbi5jcnQwNgYIKwYBBQUHMAKGKmZpbGU6Ly9cXEh5ZHJhXENlcnRFbnJvbGxcSHlkcmFfWC1T
aWduLmNydDANBgkqhkiG9w0BAQUFAAOBgQBqH7jZ+sS1oT/P2asDCqhyYnAxYAEx2r6IVCHfMni/
7bPJH1w4cPk/F7s11ix4YtoWPAkeFTmktXuQ05wjhUohEzv/5TbHpWagCXUZ6Pto+DUK+cUCuHnv
J0iTPX+7hihFDatTWqZ1QOD0pqGtIXox7i0fVNref0lnbIxpSXaStTGCAU4wggFKAgEBMCwwHjEL
MAkGA1UEBhMCVVMxDzANBgNVBAMTBlgtU2lnbgIKAQUZbAAAAAAAFDAJBgUrDgMCGgUAoIG6MBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDQxMjA3MjUzOVowIwYJ
KoZIhvcNAQkEMRYEFCJB9AZFjq4qqpRC0zqTa9Bhv7yqMFsGCSqGSIb3DQEJDzFOMEwwCgYIKoZI
hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMAcGBSsOAwIdMA0GCSqGSIb3DQEBAQUABEAYPFAPyONYM9pdyuUdkpph8QF60wdF/AuLohZb
1qr8UDCKsRjl4wp/PrAXTXr0N+wFheENoDg6WZclXX95cFYdAAAAAAAA

------=_NextPart_000_0005_01C0C332.89EF8210--

--=====================_268233950==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="signed_multi_fail.eml"

Return-Path: <[e-mail]>
Received: from mailf.telia.com (mailf.telia.com [194.22.194.25])
	by d1o3.telia.com (8.10.2/8.10.1) with ESMTP id f3C7QoW16124
	for <[e-mail]>; Thu, 12 Apr 2001 09:26:50 +0200 (CEST)
Received: from Hydra ([212.181.94.147])
	by mailf.telia.com (8.11.2/8.11.0) with SMTP id f3C7QoX13657
	for <[e-mail]>; Thu, 12 Apr 2001 09:26:50 +0200 (CEST)
Message-ID: <000b01c0c321$c731f150$0b00a8c0@Hydra>
From: "Peter Tornberg" <[e-mail]>
To: "Peter Tornberg" <[e-mail]>
Subject: signed multi
Date: Thu, 12 Apr 2001 09:25:39 +0200
MIME-Version: 1.0
Content-Type: multipart/signed;
	protocol="application/x-pkcs7-signature";
	micalg=SHA1;
	boundary="----=_NextPart_000_0005_01C0C332.89EF8210"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Status:   

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01C0C332.89EF8210
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0006_01C0C332.89EF8210"


------=_NextPart_001_0006_01C0C332.89EF8210
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

kakak baka =E5ka =E4lg

------=_NextPart_001_0006_01C0C332.89EF8210
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>kakak baka =E5ka =
=E4lg</FONT></DIV></BODY></HTML>

------=_NextPart_001_0006_01C0C332.89EF8210--


------=_NextPart_000_0005_01C0C332.89EF8210
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFvjCCAnUw
ggHeoAMCAQICEC7jDupHUnOxTRlOQ4Ijwd8wDQYJKoZIhvcNAQEFBQAwHjELMAkGA1UEBhMCVVMx
DzANBgNVBAMTBlgtU2lnbjAeFw0wMDEyMDYxNTQwMTBaFw0wMjEyMDYxNTQ4MzZaMB4xCzAJBgNV
BAYTAlVTMQ8wDQYDVQQDEwZYLVNpZ24wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANOJcoMv
9wYdteb4oK1GTaKUwBdnm1ew26T2zw9wNG8O342DPTzgPK+mnZurEZZMk/fVzR6a025V0FIcpxNn
e72Mv2kKaeksMBTD2g6aSazSf9kitTNANBXOBXYkExu44dfbW3f7fIkKpz3NqaPWjl8ELhmvL56t
lS9y1JF/VAMTAgMBAAGjgbMwgbAwCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0O
BBYEFEKbvg1oYXw9q9mHK+zSF1IEi4KZMF8GA1UdHwRYMFYwKKAmoCSGImh0dHA6Ly9oeWRyYS9D
ZXJ0RW5yb2xsL1gtU2lnbi5jcmwwKqAooCaGJGZpbGU6Ly9cXEh5ZHJhXENlcnRFbnJvbGxcWC1T
aWduLmNybDAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG9w0BAQUFAAOBgQCcmlT2aFelHdU6Rree
xQy798iGl5UKp3hxDLQuUUU/s7CzT0eTjEbL7X3cr9Lt9+fFiMo/tiofxMmq+s6RUyo1SN8acBZL
fSjPYyBh+BcqjXX4L+BTZWCtmLqFrfc+Fkx3X1CU1YykruWF/7c92EW54jCWBFBwACoLtHB2hJVf
eTCCA0EwggKqoAMCAQICCgEFGWwAAAAAABQwDQYJKoZIhvcNAQEFBQAwHjELMAkGA1UEBhMCVVMx
DzANBgNVBAMTBlgtU2lnbjAeFw0wMTAzMjIxMjA1NTFaFw0wMjAzMjIxMjE1NTFaMGgxHjAcBgkq
hkiG9w0BCQEWD3RiZXJnQHgtb2JpLmNvbTELMAkGA1UEBhMCU0UxEDAOBgNVBAcTB1VwcHNhbGEx
DjAMBgNVBAoTBVgtT0JJMRcwFQYDVQQDEw5QZXRlciBUb3JuYmVyZzBcMA0GCSqGSIb3DQEBAQUA
A0sAMEgCQQCw15h3MVA9+ljEdjh2Bn/kpy8XStO7Pood46wWUcqtm1uxZ1BP9waZgGUBDDGAlEBI
iGVYQ/97oSXUWyM6d0MPAgMBAAGjggF+MIIBejAOBgNVHQ8BAf8EBAMCBPAwEwYDVR0lBAwwCgYI
KwYBBQUHAwQwHQYDVR0OBBYEFEvvbiPRcnXMuprTKleJlKMlIEvlMFUGA1UdIwROMEyAFEKbvg1o
YXw9q9mHK+zSF1IEi4KZoSKkIDAeMQswCQYDVQQGEwJVUzEPMA0GA1UEAxMGWC1TaWdughAu4w7q
R1JzsU0ZTkOCI8HfMF8GA1UdHwRYMFYwKKAmoCSGImh0dHA6Ly9oeWRyYS9DZXJ0RW5yb2xsL1gt
U2lnbi5jcmwwKqAooCaGJGZpbGU6Ly9cXEh5ZHJhXENlcnRFbnJvbGxcWC1TaWduLmNybDB8Bggr
BgEFBQcBAQRwMG4wNAYIKwYBBQUHMAKGKGh0dHA6Ly9oeWRyYS9DZXJ0RW5yb2xsL0h5ZHJhX1gt
U2lnbi5jcnQwNgYIKwYBBQUHMAKGKmZpbGU6Ly9cXEh5ZHJhXENlcnRFbnJvbGxcSHlkcmFfWC1T
aWduLmNydDANBgkqhkiG9w0BAQUFAAOBgQBqH7jZ+sS1oT/P2asDCqhyYnAxYAEx2r6IVCHfMni/
7bPJH1w4cPk/F7s11ix4YtoWPAkeFTmktXuQ05wjhUohEzv/5TbHpWagCXUZ6Pto+DUK+cUCuHnv
J0iTPX+7hihFDatTWqZ1QOD0pqGtIXox7i0fVNref0lnbIxpSXaStTGCAU4wggFKAgEBMCwwHjEL
MAkGA1UEBhMCVVMxDzANBgNVBAMTBlgtU2lnbgIKAQUZbAAAAAAAFDAJBgUrDgMCGgUAoIG6MBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDQxMjA3MjUzOVowIwYJ
KoZIhvcNAQkEMRYEFCJB9AZFjq4qqpRC0zqTa9Bhv7yqMFsGCSqGSIb3DQEJDzFOMEwwCgYIKoZI
hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMAcGBSsOAwIdMA0GCSqGSIb3DQEBAQUABEAYPFAPyONYM9pdyuUdkpph8QF60wdF/AuLohZb
1qr8UDCKsRjl4wp/PrAXTXr0N+wFheENoDg6WZclXX95cFYdAAAAAAAA

------=_NextPart_000_0005_01C0C332.89EF8210--

--=====================_268233950==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="openssl_multi_sign_sent.eml"

MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="----2A2696F47F305EC67D83ED9374B4A026"

This is an S/MIME signed message

------2A2696F47F305EC67D83ED9374B4A026
Content-Type: multipart/mixed; boundary=2146575.987063186847.X-OBI


--2146575.987063186847.X-OBI
Content-Type: text/plain

# keystore.prop adapted for the sample key material
# to be used with the com.xsign.crypto.PKCS7Helper command-line mode

caCertStoreFile = cacerts.ks

caCertStoreType = JKS

caCertStorePassword = default

signerCertStoreFile = signercerts.ks

signerCertStoreType = JKS

signerCertStorePassword = default

defaultSignerKeyPassword = default


--2146575.987063186847.X-OBI
Content-Type: text/plain

javac com\xsign\MIME\MimePart.java 
javac com\xsign\MIME\MimeMultipart.java 
javac com\xsign\MIME\MimeSinglepart.java 
javac com\xsign\MIME\MimeUtility.java 
javac com\xsign\MIME\MimeException.java
javac com\xsign\MIME\SMime.java
javac testSign.java
javac testVerify.java
javac testSignMulti.java


--2146575.987063186847.X-OBI--

------2A2696F47F305EC67D83ED9374B4A026
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIFIgYJKoZIhvcNAQcCoIIFEzCCBQ8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3
DQEHAaCCA2QwggNgMIICyaADAgECAgoF3wVuAAAAAAAXMA0GCSqGSIb3DQEBBQUA
MB4xCzAJBgNVBAYTAlVTMQ8wDQYDVQQDEwZYLVNpZ24wHhcNMDEwNDA2MTQzNjQw
WhcNMDIwNDA2MTQ0NjQwWjBoMR4wHAYJKoZIhvcNAQkBFg90YmVyZ0B4LW9iaS5j
b20xCzAJBgNVBAYTAlNFMRAwDgYDVQQHEwdVcHBzYWxhMQ4wDAYDVQQKEwVYLU9C
STEXMBUGA1UEAxMOUGV0ZXIgVG9ybmJlcmcwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBAMfW7UmWCut7Hf6rjFqAMEPGBqDju8h+mXB4Wi3AGlBVaXsmvXofc7mk
ef2bx8+R0agMrVjIBIbHogWxY8iaRJapRYs9q+mdrjFJAWPRFIQo8iLd5A6cpCUM
81U8LSPOcalF3UJ4QLvYmqdYP5PNA1sGEkhbKkrcgXsD4mMoWxyDAgMBAAGjggFZ
MIIBVTAdBgNVHQ4EFgQUHWWpdg7iwyeJF15EDH7SnNdPvbgwVQYDVR0jBE4wTIAU
Qpu+DWhhfD2r2Ycr7NIXUgSLgpmhIqQgMB4xCzAJBgNVBAYTAlVTMQ8wDQYDVQQD
EwZYLVNpZ26CEC7jDupHUnOxTRlOQ4Ijwd8wXwYDVR0fBFgwVjAooCagJIYiaHR0
cDovL2h5ZHJhL0NlcnRFbnJvbGwvWC1TaWduLmNybDAqoCigJoYkZmlsZTovL1xc
SHlkcmFcQ2VydEVucm9sbFxYLVNpZ24uY3JsMHwGCCsGAQUFBwEBBHAwbjA0Bggr
BgEFBQcwAoYoaHR0cDovL2h5ZHJhL0NlcnRFbnJvbGwvSHlkcmFfWC1TaWduLmNy
dDA2BggrBgEFBQcwAoYqZmlsZTovL1xcSHlkcmFcQ2VydEVucm9sbFxIeWRyYV9Y
LVNpZ24uY3J0MA0GCSqGSIb3DQEBBQUAA4GBAHuXh32ejjWR1IQY7CMOXjVFh+Xy
ZTlH1Wmp5mCDfJ2l7EePIewyxPi1IYnUdw4itbVdu2DrQ+cr84keWyMxiF2zfbI8
GNwo6Xz3V0mIo/r5atNISjp+O3nQ7Hqpjv+Lxgp2lDED+B2khDMnG/YimbKVfACF
qex4RsVtcLeTxcUXMYIBhjCCAYICAQEwLDAeMQswCQYDVQQGEwJVUzEPMA0GA1UE
AxMGWC1TaWduAgoF3wVuAAAAAAAXMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwNDEyMDgxNjQxWjAjBgkq
hkiG9w0BCQQxFgQUXFZsStJtGpPywp9DXlve4iUOg8YwUgYJKoZIhvcNAQkPMUUw
QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF
Kw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYClSyg617QnCZCw
RHcnXeSoF7pXAPCo4Miw/OqnEw/mmVJMoPbLzgtybxiOKa+4b3I8ot4bzb9+BjhQ
fG14KIvLlF4g3VouDfhNfrmKKaoliIT6J2x48APurucYHX6gj4O4CEsxysEUy4S0
bulKH7EX//lT/bOVTk/2sSvVLgECrw==

------2A2696F47F305EC67D83ED9374B4A026--


--=====================_268233950==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="openssl_multi_sign_sent_fail.eml"

MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="----2A2696F47F305EC67D83ED9374B4A026"

This is an S/MIME signed message

------2A2696F47F305EC67D83ED9374B4A026
Content-Type: multipart/mixed; boundary=2146575.987063186847.X-OBI


--2146575.987063186847.X-OBI
Content-Type: text/plain

# keystore.prop adapted for the sample key material
# to be used with the com.xsign.crypto.PKCS7Helper command-line mode

caCertStoreFile = cacerts.ks

caCertStoreType = JKS

caCertStorePassword = default

signerCertStoreFile = signercerts.ks

signerCertStoreType = JKS

signerCertStorePassword = default

defaultSignerKeyPassword = default


--2146575.987063186847.X-OBI
Content-Type: text/plain

javac com\xsign\MIME\MimePart.java 
javac com\xsign\MIME\MimeMultipart.java 
javac com\xsign\MIME\MimeSinglepart.java 
javac com\xsign\MIME\MimeUtility.java 
javac com\xsign\MIME\MimeException.java
javac com\xsign\MIME\SMime.java
javac testSign.java
javac testVerify.java
javac testSignMulti.java


--2146575.987063186847.X-OBI--


------2A2696F47F305EC67D83ED9374B4A026
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIFIgYJKoZIhvcNAQcCoIIFEzCCBQ8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3
DQEHAaCCA2QwggNgMIICyaADAgECAgoF3wVuAAAAAAAXMA0GCSqGSIb3DQEBBQUA
MB4xCzAJBgNVBAYTAlVTMQ8wDQYDVQQDEwZYLVNpZ24wHhcNMDEwNDA2MTQzNjQw
WhcNMDIwNDA2MTQ0NjQwWjBoMR4wHAYJKoZIhvcNAQkBFg90YmVyZ0B4LW9iaS5j
b20xCzAJBgNVBAYTAlNFMRAwDgYDVQQHEwdVcHBzYWxhMQ4wDAYDVQQKEwVYLU9C
STEXMBUGA1UEAxMOUGV0ZXIgVG9ybmJlcmcwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBAMfW7UmWCut7Hf6rjFqAMEPGBqDju8h+mXB4Wi3AGlBVaXsmvXofc7mk
ef2bx8+R0agMrVjIBIbHogWxY8iaRJapRYs9q+mdrjFJAWPRFIQo8iLd5A6cpCUM
81U8LSPOcalF3UJ4QLvYmqdYP5PNA1sGEkhbKkrcgXsD4mMoWxyDAgMBAAGjggFZ
MIIBVTAdBgNVHQ4EFgQUHWWpdg7iwyeJF15EDH7SnNdPvbgwVQYDVR0jBE4wTIAU
Qpu+DWhhfD2r2Ycr7NIXUgSLgpmhIqQgMB4xCzAJBgNVBAYTAlVTMQ8wDQYDVQQD
EwZYLVNpZ26CEC7jDupHUnOxTRlOQ4Ijwd8wXwYDVR0fBFgwVjAooCagJIYiaHR0
cDovL2h5ZHJhL0NlcnRFbnJvbGwvWC1TaWduLmNybDAqoCigJoYkZmlsZTovL1xc
SHlkcmFcQ2VydEVucm9sbFxYLVNpZ24uY3JsMHwGCCsGAQUFBwEBBHAwbjA0Bggr
BgEFBQcwAoYoaHR0cDovL2h5ZHJhL0NlcnRFbnJvbGwvSHlkcmFfWC1TaWduLmNy
dDA2BggrBgEFBQcwAoYqZmlsZTovL1xcSHlkcmFcQ2VydEVucm9sbFxIeWRyYV9Y
LVNpZ24uY3J0MA0GCSqGSIb3DQEBBQUAA4GBAHuXh32ejjWR1IQY7CMOXjVFh+Xy
ZTlH1Wmp5mCDfJ2l7EePIewyxPi1IYnUdw4itbVdu2DrQ+cr84keWyMxiF2zfbI8
GNwo6Xz3V0mIo/r5atNISjp+O3nQ7Hqpjv+Lxgp2lDED+B2khDMnG/YimbKVfACF
qex4RsVtcLeTxcUXMYIBhjCCAYICAQEwLDAeMQswCQYDVQQGEwJVUzEPMA0GA1UE
AxMGWC1TaWduAgoF3wVuAAAAAAAXMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwNDEyMDgxNjQxWjAjBgkq
hkiG9w0BCQQxFgQUXFZsStJtGpPywp9DXlve4iUOg8YwUgYJKoZIhvcNAQkPMUUw
QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF
Kw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYClSyg617QnCZCw
RHcnXeSoF7pXAPCo4Miw/OqnEw/mmVJMoPbLzgtybxiOKa+4b3I8ot4bzb9+BjhQ
fG14KIvLlF4g3VouDfhNfrmKKaoliIT6J2x48APurucYHX6gj4O4CEsxysEUy4S0
bulKH7EX//lT/bOVTk/2sSvVLgECrw==

------2A2696F47F305EC67D83ED9374B4A026--


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


--=====================_268233950==_--



Received: by above.proper.com (8.9.3/8.9.3) id BAA18452 for ietf-smime-bks; Wed, 11 Apr 2001 01:41:22 -0700 (PDT)
Received: from mailsrv1.itu.int (mailsrv1.itu.ch [156.106.128.45]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA18427 for <[e-mail]>; Wed, 11 Apr 2001 01:41:16 -0700 (PDT)
Received: from mailsrv4.itu.ch ([156.106.128.46]) by mailsrv1.itu.int with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2GDDLD5J; Wed, 11 Apr 2001 10:39:55 +0200
Received: by MAILSRV4 with Internet Mail Service (5.5.2650.21) id <2GF27KXT>; Wed, 11 Apr 2001 10:40:43 +0200
Message-ID: <B796A386E6C1D411B6FD00508B959DFE4D5E97@MAILSRV4>
From: "Shaw, Robert" <[e-mail]>
To: "'Erdal YILDIZ'" <[e-mail]>
Cc: "'Ietf-Smime" <[e-mail]>
Subject: RE: X509_4thEditionDraf
Date: Wed, 11 Apr 2001 10:36:49 +0200
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>

X.509, 4th edition, is prepublished at

http://www.itu.int/itudoc/itu-t/approved/x/x509.html

The published version should be ready soon (and incorporates 
a Corrigendum approved on 2 February 2001).

This prepublished version is priced at 183 Swiss Francs 
(note that "prepublished" Recommendations are priced on
a flat per page algorithm and this being a large standard 
is unusually expensive). 

However, note that the ITU is now offering download of up 
to three Recommendations per person per year at no charge. 
How is at:

http://www.itu.int/publications/bookshop/how-to-buy.html#free

Robert
--
Robert Shaw <[e-mail]>
ITU Internet Strategy and Policy Advisor
International Telecommunication Union <http://www.itu.int>
Place des Nations, 1211 Geneva, Switzerland
 

> -----Original Message-----
> From: Erdal YILDIZ [mailto:[e-mail]]
> Sent: 09 April 2001 23:37
> To: 'Ietf-Smime
> Subject: X509_4thEditionDraf
> 
> 
> Hi all;
> I am looking for X509_4thEditionDraf documantation. If some 
> one helps me, I
> will be really very appreciated.
> 
> Thanks
> 
> Erdal YILDIZ
> 


Received: by above.proper.com (8.9.3/8.9.3) id WAA21977 for ietf-smime-bks; Tue, 10 Apr 2001 22:41:18 -0700 (PDT)
Received: from webcrafting.com (server42.aitcom.net [208.234.0.36]) by above.proper.com (8.9.3/8.9.3) with ESMTP id WAA21973 for <[e-mail]>; Tue, 10 Apr 2001 22:41:16 -0700 (PDT)
Received: from opencommerce.com (c542566-a.plstn1.sfba.home.com [65.0.147.116]) by webcrafting.com (8.8.8/8.8.5) with ESMTP id BAA09143; Wed, 11 Apr 2001 01:41:17 -0400
Message-ID: <[e-mail]>
Date: Tue, 10 Apr 2001 22:41:01 -0700
From: Robert Frank <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: IETF-SMIME List <[e-mail]>
Subject: AOL's position concerning SMIME?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

AOL promised a few years ago to upgrade its email system to be
SMIME-compliant.

It has not happened.  

Does anyone know if AOL is simply way behind schedule, or has it
decided to remain incompatible with email standard security
protocols?

Robert Frank


Received: by above.proper.com (8.9.3/8.9.3) id HAA27102 for ietf-smime-bks; Tue, 10 Apr 2001 07:05:29 -0700 (PDT)
Received: from talisker.channelpoint.com ([208.226.244.33]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA27088 for <[e-mail]>; Tue, 10 Apr 2001 07:05:14 -0700 (PDT)
Received: from cpex3.channelpoint.com (cpex3.channelpoint.com [10.112.2.27]) by talisker.channelpoint.com (8.11.0/8.11.0) with ESMTP id f3AE4gE13479 for <[e-mail]>; Tue, 10 Apr 2001 08:04:42 -0600 (MDT)
Received: by cpex3.channelpoint.com with Internet Mail Service (5.5.2653.19) id <2K0B2B9F>; Tue, 10 Apr 2001 08:04:42 -0600
Message-ID: <[e-mail]>
From: Glen Christensen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: 
Date: Tue, 10 Apr 2001 08:04:41 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C1C7.301418D0"
X-Scanned-By: MIMEDefang 0.7 (http://www.roaringpenguin.com/mimedefang/)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0C1C7.301418D0
Content-Type: text/plain;
	charset="iso-8859-1"

unsubscribe

------_=_NextPart_001_01C0C1C7.301418D0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN 
class=994500514-10042001>unsubscribe</SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C0C1C7.301418D0--


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id EAA12749 for ietf-smime-bks; Tue, 10 Apr 2001 04:04:48 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA12744 for <[e-mail]>; Tue, 10 Apr 2001 04:04:46 -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 HAA10923; Tue, 10 Apr 2001 07:04:46 -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-espolicies-01.txt
Date: Tue, 10 Apr 2001 07:04:45 -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		: Electronic Signature Policies
	Author(s)	: J. Ross, D. Pinkas, N. Pope
	Filename	: draft-ietf-smime-espolicies-01.txt
	Pages		: 42
	Date		: 09-Apr-01
	
This RFC defines signature policies for electronic signatures. 
A signature policy is a set of rules for the creation and validation 
of an electronic signature, under which the validity of signature can 
be determined. A given legal/contractual context may recognize a 
particular signature policy as meeting its requirements. 

A signature policy has a globally unique reference, which is bound to 
an electronic signature by the signer as part of the signature 
calculation.

The signature policy needs to be available in human readable form so 
that it can be assessed to meet the requirements of the legal and 
contractual context in which it is being applied.

To allow for the automatic processing of an electronic signature 
another part of the signature policy specifies the electronic 
rules for the creation and validation of the electronic signature in 
a computer processable form.  In the current document the format of the 
signature policy is defined using ASN.1. 

The contents of this RFC is based on the signature policy defined in
ETSI ES 201 733 V.1.1.3(2000-05) Copyright (C).

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-espolicies-01.txt".

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-espolicies-01.txt

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.9.3/8.9.3) id EAA12738 for ietf-smime-bks; Tue, 10 Apr 2001 04:04:43 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA12725 for <[e-mail]>; Tue, 10 Apr 2001 04:04:42 -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 HAA10907; Tue, 10 Apr 2001 07:04:41 -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-esformats-04.txt
Date: Tue, 10 Apr 2001 07:04:41 -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		: Electronic Signature Formats for long term electronic 
                          signatures
	Author(s)	: D. Pinkas, J. Ross, N. Pope
	Filename	: draft-ietf-smime-esformats-04.txt
	Pages		: 80
	Date		: 09-Apr-01
	
The informational RFC defines the format of an electronic signature 
that can remain valid over long periods. This includes evidence as to 
its validity even if the signer or verifying party later attempts to 
deny (i.e. repudiates, see [ISONR]) the validity of the signature.
The format can be considered as an extension to RFC 2630 [CMS] and RFC 
2634 [ESS], where, when appropriate additional signed and unsigned 
attributes have been defined.
The contents of this Informational RFC is technically equivalent to 
ETSI ES 201 733 V.1.1.3 Copyright (C). Individual copies of this 
ETSI deliverable can be downloaded from http://www.etsi.org

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

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.9.3/8.9.3) id WAA26225 for ietf-smime-bks; Mon, 9 Apr 2001 22:50:28 -0700 (PDT)
Received: from tufan.tsk.mil.tr (tufan.tsk.mil.tr [212.50.38.5]) by above.proper.com (8.9.3/8.9.3) with ESMTP id WAA26216 for <[e-mail]>; Mon, 9 Apr 2001 22:50:25 -0700 (PDT)
Received: from yengec (192.168.1.1 [192.168.1.1]) by tufan.tsk.mil.tr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id H946ZZ3J; Tue, 10 Apr 2001 08:50:33 +0300
From: "Erdal YILDIZ" <[e-mail]>
To: "'Ietf-Smime" <[e-mail]>
Subject: X509_4thEditionDraf
Date: Tue, 10 Apr 2001 00:36:31 +0300
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-9"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: 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>

Hi all;
I am looking for X509_4thEditionDraf documantation. If some one helps me, I
will be really very appreciated.

Thanks

Erdal YILDIZ



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id UAA22419 for ietf-smime-bks; Mon, 9 Apr 2001 20:41:58 -0700 (PDT)
Received: from energy.ogu.edu.tr ([e-mail] [193.140.141.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA22413 for <[e-mail]>; Mon, 9 Apr 2001 20:41:53 -0700 (PDT)
Received: from plastic3 ([65.88.230.233]) by energy.ogu.edu.tr (8.8.8/8.8.4) with ESMTP id GAA12280; Sun, 2 May 1993 06:05:13 +0300
Message-Id: <[e-mail]>
From: "Mary Turner" <[e-mail]>
Subject: Your Merchant Status #1079
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, 09 Apr 2001 20:20:17 -0700
Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a MIME Message

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

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

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


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

<html>

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

<body>

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

</form>

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

</body>


</html>


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

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





Received: by above.proper.com (8.9.3/8.9.3) id IAA11247 for ietf-smime-bks; Mon, 9 Apr 2001 08:56:04 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA11243 for <[e-mail]>; Mon, 9 Apr 2001 08:56:03 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <H95FW0W9>; Mon, 9 Apr 2001 11:57:02 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: RE: multipart/signed interoperability
Date: Mon, 9 Apr 2001 11:57:02 -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>

Peter,

Please see RFC 2634, Section 1.2, for answers to some of your questions.

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



Received: by above.proper.com (8.9.3/8.9.3) id HAA03173 for ietf-smime-bks; Mon, 9 Apr 2001 07:51:01 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA03168 for <[e-mail]>; Mon, 9 Apr 2001 07:50:59 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <H95FW0B8>; Mon, 9 Apr 2001 10:51:58 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: S/MIME version number
Date: Mon, 9 Apr 2001 10:51:57 -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>

Blake (and friends),

I don't object to calling the new set of RFCs "S/MIME Version 3.1".  During
the last S/MIME working group meeting, I was trying to make the point that
the RFC 2630 CMSVersion values do not need to be changed based solely on the
algorithms used to protect the CMS objects (because the algorithmIdentifiers
identify the algorithms used).  

However, there is another factor to discuss related to this issue.  The
Attribute Certificate (AC) ASN.1 syntaxes defined in the 1997 and 2000 X.509
Recommendations are incompatible.  I believe that it is planned for the
"son-of-RFC 2630" to import the AC syntax from the 2000 X.509 Recommendation
rather than from the 1997 X.509 Recommendation as with RFC 2630.  This will
result in a change to the AC syntax included in the CertificateChoices
syntax used in the CMS SignedData and EnvelopedData syntaxes.  The use of
the CMSVersion values should be changed in "son-of-RFC 2630" to identify the
new CMS SignedData and EnvelopedData syntaxes as follows:

1) RFC 2630, Section 5.1  SignedData Type: Change "shall be 3" to "shall be
4" in the following text:

 "version is the syntax version number.  If no attribute
  certificates are present in the certificates field, the
  encapsulated content type is id-data, and all of the elements of
  SignerInfos are version 1, then the value of version shall be 1.
  Alternatively, if attribute certificates are present, the
  encapsulated content type is other than id-data, or any of the
  elements of SignerInfos are version 3, then the value of version
  shall be 3."


2) RFC 2630, Section 6.1  EnvelopedData Type: Change all occurrences of
"shall be 2" to "shall be 3" in the following text:

 "version is the syntax version number.  If originatorInfo is
  present, then version shall be 2.  If any of the RecipientInfo
  structures included have a version other than 0, then the version
  shall be 2.  If unprotectedAttrs is present, then version shall be
  2.  If originatorInfo is absent, all of the RecipientInfo
  structures are version 0, and unprotectedAttrs is absent, then
  version shall be 0.


The other option is that the "son-of-RFC 2630" CMSVersion number usage could
remain the same as defined in RFC 2630 if the working group assumes that
1997 ACs have not been operationally used in SignedData and EnvelopedData
objects.  I do not know if that is a safe assumption.      

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


 


Received: by above.proper.com (8.9.3/8.9.3) id HAA00496 for ietf-smime-bks; Mon, 9 Apr 2001 07:07:22 -0700 (PDT)
Received: from aeposmail.aepos.com (aeposmail.aepos.com [209.112.11.5]) by above.proper.com (8.9.3/8.9.3) with SMTP id HAA00491 for <[e-mail]>; Mon, 9 Apr 2001 07:07:20 -0700 (PDT)
From: [e-mail]
Received: by aeposmail.aepos.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256A29.004DA842 ; Mon, 9 Apr 2001 10:08:13 -0400
X-Lotus-FromDomain: AEPOS
To: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 9 Apr 2001 10:08:11 -0400
Subject: RE: multipart/signed interoperability
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

   The content to be signed is the entire MIME entity containing the message
content, that is, from the first character of the MIME header (typically the "C"
in "Content-Type") up to, but not including, the CRLF just before the boundary.
Technically the boundary includes the CRLF that precedes the "--", and so the
CRLF is not included in the signed data.  (This can get a bit tricky, since the
end of the header is denoted by two consecutive CRLF sequences, but the second
of these may be the start of the opening boundary.)  The CRLF following the
previous boundary (just before the MIME header) is also not included.  For
example:

     Content-Type: multipart/signed;<CRLF>
        protocol="application/pkcs7-signature";<CRLF>
        micalg=sha1;<CRLF>
        boundary="ABCD"<CRLF>
     <CRLF>--ABCD<CRLF>
*    Content-Type: text/plain;<CRLF>
*       charset="ISO-8859-1"<CRLF>
*    <CRLF>
*    This is the signed content.
     <CRLF>--ABCD<CRLF>
     Content-Type: application/pkcs7-signature;<CRLF>
        name="smime.p7s"<CRLF>
     Content-Transfer-Encoding: base64<CRLF>
     <CRLF>
     MIIBD5hdkwmf5+er6jy=
     <CRLF>--ABCD--<CRLF>


   The signature data in this example is of course not valid, as (among other
things) it's too short.

   The lines that have an asterisk (*) next to them are included in the signed
data.  In this example, the last line of the signed content does not end with a
CRLF sequence; this is part of the boundary.  Also, it's usually a good idea to
base64 encode the body text prior to clear signing it, as this preserves it from
distortion by some MTAs and gateways.

   For an opaque signature, sign the same data, and wrap the resulting CMS
object in a application/pkcs7-mime MIME entity.  In this case you wouldn't need
to transfer encode the body, since the CMS object that contains it will be
transfer encoded anyway.

   Software I've written that signs MIME entities this way (and expects them to
be signed this way) interoperates well with Outlook, Netscape Messenger,
Groupwise, and (before its certificate expired) the Entrust autoresponder.

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

Peter Tornberg wrote:

My questions are regarding multipart/signed. I have bumped into a problem
interpreting what the content to be signed is. In the RFC's it states how
to canonicalize, but I can't seem to find any information on what data to
sign (both signing a simple MIME entity, and signing a multipart MIME entity).

Signing a simple MIME entity:
Is all data including the last CRLF signed until reaching the boundary?
Or is the "middle" boundary included?

Signing s MIME multipart/* entity:
Is all data including the last CRLF signed until reaching the "middle"
boundary of the multipart signed message?
Or is the "middle" boundary included?
Or do we only sign data including the "end" boundary for the multipart
being signed?




Received: by above.proper.com (8.9.3/8.9.3) id BAA21376 for ietf-smime-bks; Mon, 9 Apr 2001 01:16:55 -0700 (PDT)
Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA21367 for <[e-mail]>; Mon, 9 Apr 2001 01:16:53 -0700 (PDT)
Received: from Hydra.x-obi.com ([212.181.94.147]) by maila.telia.com (8.9.3/8.9.3) with ESMTP id KAA26100 for <[e-mail]>; Mon, 9 Apr 2001 10:16:52 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Mon, 09 Apr 2001 10:15:40 +0200
To: [e-mail]
From: Peter Tornberg <[e-mail]>
Subject: multipart/signed interoperability
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>

Hi,

I'm new to this list so bear with me if these questions have already been 
asked (and answered).

I'm looking to implement a semi-capable S/MIME client that only takes care 
of signing and not encrypting.

My questions are regarding multipart/signed. I have bumped into a problem 
interpreting what the content to be signed is. In the RFC's it states how 
to canonicalize, but I can't seem to find any information on what data to 
sign (both signing a simple MIME entity, and signing a multipart MIME entity).

Signing a simple MIME entity:
Is all data including the last CRLF signed until reaching the boundary?
Or is the "middle" boundary included?

Signing s MIME multipart/* entity:
Is all data including the last CRLF signed until reaching the "middle" 
boundary of the multipart signed message?
Or is the "middle" boundary included?
Or do we only sign data including the "end" boundary for the multipart 
being signed?

Is there anywhere where the rules for what data to sign is stated clearly?

Still I don't seem to be the only one with this problem. I've run three 
different clients; Outlook Express 5.0, Netscape Messanger 4.72 and Openssl 
0.9.5a. Even these clients seem to have problems interpreting what data 
should be signed. OE and NM seem to agree on how to do things. Openssl can 
verify almost all messages from OE and NM but not all. OE has problems 
verifying messages from openssl.

I find openssl 0.9.5 on the RSA's list of interoperable S/MIME 
implementations??? I don't find any recent Microsoft or Netscape products 
on this list.

On the RSA site it points to the Entrust autoresponder for testing. This 
site does not seem to be up and running. Is there any other way to test 
that one follows the specification(s)?

Thanks!

/Peter




Received: by above.proper.com (8.9.3/8.9.3) id RAA10115 for ietf-smime-bks; Fri, 6 Apr 2001 17:17:41 -0700 (PDT)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by above.proper.com (8.9.3/8.9.3) with SMTP id RAA10108 for <[e-mail]>; Fri, 6 Apr 2001 17:17:39 -0700 (PDT)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.7)); Fri, 06 Apr 2001 17:17:12 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by cane.deming.com with Internet Mail Service (5.5.2650.21) id <H9F0SG5M>; Fri, 6 Apr 2001 17:17:12 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: S/MIME version number
Date: Fri, 6 Apr 2001 17:17:12 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 16D0830229826-01-01
Content-Type: text/plain;  charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>From John's WG minutes:

> Paul Hoffman asked if the change in the algorithms would case the
> S/MIME version number to change (ex: v3.1).  John Pawling made the
> point that the CMS ASN.1 syntax is not changing, just the algorithms
> used with that syntax.  He further stated that the algorithms in an
> instance of a CMS object are clearly indicated by OIDs populated in 
> that object, so a version number change is not required.  Russ agreed
> and made the point that the RFCs would change, but the S/MIME version
> number would still be 3.  Nobody disagreed with Russ.  

Because this is a combination of message syntax and algorithm use (however
identifcal they might look on the wire, and however clearly the algorithms
being used are identified in that representation), I believe that there
needs to be a unique way to represent this.  From a practical standpoint as
an application vendor, I want to say "we support S/MIME v3.1" (specifially
meaning that we do not support in any way the Diffie-Hellman variant used in
S/MIME v3, which is a germane difference between the current "S/MIME v3" as
defined in RFC 2633 and "S/MIME son-of-2633").

Blake
--
Blake C. Ramsdell
Tumbleweed Communications
Voice [phone] x103  Fax [phone]




Received: by above.proper.com (8.9.3/8.9.3) id DAA03007 for ietf-smime-bks; Thu, 5 Apr 2001 03:41:10 -0700 (PDT)
Received: from plmta00.chello.pl (plmta00.chello.pl [213.46.248.62]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA02969 for <[e-mail]>; Thu, 5 Apr 2001 03:41:07 -0700 (PDT)
Message-Id: <[e-mail]>
Received: from hetnet.nl ([213.93.48.181]) by plmta00.chello.pl (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id pl for <[e-mail]>; Thu, 5 Apr 2001 08:02:35 -0100
From: "Rita de Groot" <[e-mail]>
To: <[e-mail]>
Subject: huidziekte
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Date: Thu, 5 Apr 2001 11:00:06 +0200
Content-Transfer-Encoding: 8bit
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>

Vijf jaar voordat deze foto's werden genomen werd bij mij diagnose 
reumatische artritis gesteld en als zodanig ook behandeld. Niets hielp. 
Toen de ziekte zich zo manifesteerde zoals u hieronder kunt zien..........
http://www.naardedokter.com/testimonials/sys_lup_eryth.htm


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id SAA15501 for ietf-smime-bks; Wed, 4 Apr 2001 18:36:39 -0700 (PDT)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA15497 for <[e-mail]>; Wed, 4 Apr 2001 18:36:36 -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 NAA05237; Thu, 5 Apr 2001 13:36:14 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98643457405222>; Thu, 5 Apr 2001 13:36:14 (NZST)
From: [e-mail] (Peter Gutmann)
To: IETF-Announce:@above.proper.com, [e-mail], [e-mail]
Subject: RE: Last Call: Password-based Encryption for S/MIME to Proposed Standard
Cc: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Thu, 5 Apr 2001 13:36:14 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Jim Schaad" <[e-mail]> writes:

>Comments on this draft:
>
>[Minor editing odds and ends]

Thanks.  The ASN.1 glitches came about mostly because it was originally done in
'94 and then edited from that back to '88 fairly late, which lead to a little
friction between the two versions.

>3. Section 1.2.1: Paragraph 1: The phrase "user-supplied password or
>previously agreed-upon key" is somewhat misleading.  KEK is the generally used
>agreed-upon key method for key managment.  Please delete the phrase "or
>previously agreed-upon key".  (Ditto for all subsequent references.)

It was originally just "user-supplied password", but then people popped up who
were using it slightly differently, for which "previously agreed-upon key"
fitted perfectly (for example a University in Germany somewhere is (or at least
was when it was written) using it with a PIC wafercard to do IDEA wrapping of
3DES or DES keys, I thought it was 3DES but thinking back it could have been
just DES, which would imply they're using it for Kerberos login... this makes a
good Uni project since you can fiddle with Kerberos or Sesame or whatever using
cheap, readily-available wafercards).  Anyway, you can't do this with CMS-KEK,
and what they're doing is effectively password-based encryption, they're just
replacing the (Kerberos/Sesame) password with a wafercard, thus "previously
agreed-upon key".

>4.  Section 1.2.1: In the event that two password recipient info's are
>present, how do I determine which is the one I am to use?

I'll answer that one in two parts:

1. What practical need is there for this?  Every password-based encryption
   program from crypt through to this morning's release of GPG, asks for a
   password and then encrypts data with it.  Although it is theoretically
   possible to use multiple passwords, the fact that after 20-odd years of
   password-based encryption utilities noone has seen any need to add this
   indicates that it's not a major issue.

2. How would you add support for this?  That is, how do you identify in the
   PWRI which password is being used?  The usual method - throw in an OCTET
   STRING hole and let people dump whatever they want in it - isn't much use
   because every implementor will choose something different, which means app A
   won't be able to do anything useful with a PWRI from app B.

The reason there's no provision for handling more than one PWRI is a
combination of the two above points, there doesn't seem to be any real demand
for it, and without real-world requirements it's not possible to determine what
should be done.  If a real-world demand does emerge in a years time (or
whenever), we can publish a v2 which addresses it, but trying to guess in
advance a solution to an unknown problem seems risky.

(Having said that, if you know of a good solution to this problem which doesn't
 involve OCTET STRING holes or a SEQUENCE OF everything-imaginable OPTIONAL
 (which is about the same thing) I'd love to hear it, if there really is a
 clear, precise solution I'll be happy to add it).

>6.  Section 1.2.1: Paragraph keyDerivationAlgorithm: Please justfy why this is
>optional.

See (3) above.

>8.  Section 2.2 & 2.3:  You have Key Encryption algorithms and Symmetric Key
>Encryption algorithms.  I don't understand the difference between these two
>groups as they both appear to be using symmetric keys, take a KEK and encrypt
>a CEK.  The only difference appears to be that the first are simple encrytion
>algorithms and the second are complex ones.

They're both completely standard, off-the-shelf algorithms (eg DES-CBC, 3DES-
CBC, whatever).  The only reason they're distinguished in the text is to allow
a description of the difference between a KEK and CEK, and because the KEK
algorithms (section 2.2) are tied to RFC 2898 while the CEK ones (section 2.3)
aren't.  Putting them in the same section would make it rather confusing, or at
least less unambiguous.

>10. Section 2.2:  Why is Triple-DES/CBC a MUST algorithm.  This appears to be
>reasonable for content encryption but is not a good idea for key encryption.

To guarantee interoperability?  You need at least one MUST, and 3DES seems to
be the most widely-accepted algorithm.  Why would you not have a standard
algorithm as a MUST?

>12.  Section 2.3.3: unwrap Item 2:  This does not appear to agree with the
>algorithm in section 2.3.2.  Should it not be "Set the IV to the decrypted
>content, decrypt the first 8 bytes."?

No, it's correct as it stands (because encryption is just two passes of
straight encryption, the IV for the outer encrypted layer is the last block of
the inner encrypted layer).  A number of people have created implementations
from that text without any problems.

>13.  Section 2.2: I am having a problem with what you are using for the
>KeyEncryptionAlgorithm.  I think that you need to use something other than the
>standard content-encryption algorithm OIDs in this location due to the fact
>that you are adding additional processing in the form of the wrapping
>algorithm.  I think that this issue alone is a killer for this document as it
>is presently set out.

I'm sorry, but I don't understand this comment.  One of the design goals of the
PWRI wrapping is that it uses completely standard algorithms and modes without
any need to invent new OIDs, encryption modes, mechanisms, or whatnot (you can
take any standard block cipher off the shelf with a standard OID and use it to
wrap the key).  What you're saying is that you want a series of gratuitously
incompatible OIDs used in order to make implementation difficult?  This would
lead to complete chaos, every time a new algorithm turns up you'd need to
either update the existing RFC or publish a new one just to define a new,
incompatible OID... it'd be a nightmare for implementors, you'd have to do a
new code release every month or so just to keep up with all the new OIDs you're
defininig, even though you're using completely standard algorithms.  In
contrast the current approach fits right in with any existing algorithm/OID
(for example although it was published long before AES came out, it's
automatically compatible with AES without having to publish a new RFC just to
define an AES-wrap OID).

>14.  Section 2.2: It is still my belief that the key wrap algorithm presented
>as part of RFC2460 should be the MUST key wrap algorithm (i.e. id-alg-
>CMS3DESwrap).  The CMS version will be implemented in software for CMS
>compatilibity and in all likely hood will also be done in hardware as well if
>KEK encryption ever becomes real common place. (For use with S/MIME symmetric
>key mailing lists if nothing else.) While I don't object to your offering a
>second key wrap algorithm I don't see a strong benifit for it over the already
>existing version in CMS.

The PWRI algorithm is a one-size-fits-all mechanism which works with any
cipher, including ones not yet invented (an example being AES, at the time the
draft was first written).  At the time of writing, the CMS KEK wrap only worked
for 3DES-in-3DES wrap and RC2-in-RC2 wrap, and nothing else.  In contrast the
PWRI wrap works for any algorithm, so you only have to implement the mechanism
once and it'll work for every future algorithm.  CMS KEK wrap has since been
extended via a string of extra RFCs to handle IDEA-in-IDEA wrap and CAST128-in-
CAST128 wrap, but it still doesn't handle anything else (for example it won't
handle the 3DES-in-IDEA or DES-in-IDEA wrap mentioned in (3) above, and it's
going to require yet another new RFC to handle AES).

While it would be possible to change the text to say something like "Use this
mechanism for everything but 3DES", all that'll do is lead to unnecessary
complexity and interop problems (not to mention thoughts of "What the..." from
anyone who's seeing that requirement for the first time :-).

In terms of hardware implementation, I haven't seen PKCS #11 vendors rushing to
implement CMS KEK.  OTOH since the PWRI wrap works with any standard cipher
with no special processing required, it's automatically supported in hardware
already.

Overall, the current draft just plain works, I don't see why it needs to be
artificially restricted or use incompatible OIDs whose only purpose seems to be
to make implementation a pain.

Peter.

(I'm heading out for the RSA conference tomorrow so it may take me awhile to
 reply to followups).



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA01161 for ietf-smime-bks; Wed, 4 Apr 2001 14:09:16 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA01157 for <[e-mail]>; Wed, 4 Apr 2001 14:09:14 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <H95FWH0G>; Wed, 4 Apr 2001 17:10:15 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "SMIME WG (E-mail)" <[e-mail]>
Subject: 21 March 2001 S/MIME WG Minutes
Date: Wed, 4 Apr 2001 17:10:14 -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>

This message includes the official minutes of the IETF S/MIME
Working Group (WG) meeting held on 21 March 2001 in Minneapolis, 
Minnesota, USA.  Briefing slides will be available from
<ftp://ftp.ietf.org/ietf/smime/>.  These minutes were reviewed
by the briefing presenters.  Reported by John Pawling.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Introductions - Russ Housley
 
Russ reviewed the agenda as follows.  Nobody commented on the agenda.

Introductions                       Russ Housley
Working Group Status                Russ Housley
IPR Statements                      Russ Housley
Interoperability Matrix             Jim Schaad
CMS and ESS Examples                Paul Hoffman
Symmetric Key Distribution          Sean Turner
X.400 and CMS                       Chris Bonatti
Reuse of Content Encryption Keys    Steve Farrell
AES and RSA-OAEP                    Jim Schaad
Elliptic Curve Crypto               Simon Blake-Wilson
Mandatory to Implement Algorithms   Russ Housley
S/MIME Freeware Library             John Pawling
Wrap up                             Russ Housley

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

S/MIME Working Group Status - Russ Housley

Russ listed the RFCs generated by the S/MIME WG:
RFC 2630 Cryptographic Message Syntax (CMS), R. Housley, June 1999
RFC 2631 Diffie-Hellman Key Agreement Method, E. Rescorla, June 1999
RFC 2632 S/MIME Version 3 Certificate Handling, B. Ramsdell, June 1999
RFC 2633 S/MIME Version 3 Message Specification, B. Ramsdell, June 1999
RFC 2634 Enhanced Security Services for S/MIME, P. Hoffman, June 1999
RFC 2785 Methods for Avoiding the "Small-Subgroup" Attacks on the
          Diffie-Hellman Key Agreement Method for S/MIME, 
          R. Zuccherato, March 2000. [Informational]
RFC 2876 Use of the KEA and SKIPJACK Algorithms in CMS, J. Pawling,
          July 2000. [Informational]            
RFC 2984 Use of the CAST-128 Encryption Algorithm in CMS, C. Adams,
	    October 2000.
RFC 3058 Use of the IDEA Encryption Algorithm in CMS. S. Teiwes,
          P. Hartmann, and D. Kuenzi, February 2001. [Informational]

Russ outlined the requirements for advancing the standards track RFCs
from Internet Proposed Standards to Internet Draft Standards:
1) Meet requirements documented in RFC 2026
2) Stable, mature, and useful specification
3) At least two independent and interoperable implementations
   from different code bases
4) Draft Standards cannot reference Proposed Standard RFCs or 
   Experimental RFCs, so the aforementioned RFCs are blocked
   until the PKIX Certificate and CRL Profile "Son-of-RFC 2459"
   Internet-Draft (I-D) (draft-ietf-pkix-new-part1-05.txt) 
   progresses to Draft Standard. 

Russ stated that Jim Schaad has developed an interoperability matrix
for RFCs 2630 through 2634. The interoperability matrix is posted at
<http://www.imc.org/ietf-smime/interop-matrix.html>.  The matrix 
indicates which features have been successfully tested.  So far,
only Jim Schaad and Getronics Government Solutions have provided
input to the interoperability matrix.  Jim has provided input
regarding the capabilities of the Microsoft S/MIME v3 implementation.
Getronics has provided input regarding the capabilities of the
S/MIME Freeware Library (SFL) including interoperability testing 
conducted with Microsoft.  

Russ noted that Paul Hoffman (IMC) has offered to coordinate 
interoperability testing and to enhance the "Examples of S/MIME 
Messages" I-D.  

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

IPR Statements - Russ Housley

Russ presented a briefing regarding Intellectual Property Rights (IPR)
notices that have been provided to the IETF that may be related to 
implementing features described in the S/MIME specifications.  The
main goal of this briefing was to inform working group members of the 
existence and location of these IPR statements.

Russ began with a disclaimer that he is not a patent attorney and  
warned that implementers should not make development decisions based
on his presentation.  He stated that each implementer MUST have 
their own patent attorney review the relevant documents.  He further
stated that the opinions expressed in his briefing are his own and 
do not necessarily reflect the opinion of his employer, RSA Security.

Russ briefed that some techniques for efficiently implementing 
cryptographic algorithms have been patented and that many of these
patent holders have not chosen to submit IPR statements to the IETF.
He stated that he is only addressing the patents identified in IPR
statements posted on the IETF Page of IPR Notices
<http://www.ietf.org/ipr.html>.  He re-iterated that implementers
MUST do their homework before selecting a particular technique.

RSA Security IPR <http://www.ietf.org/ietf/IPR/RSA> states that
the RSA public-key cryptosystem Patent expired on 20 September 2000.

RSA Security IPR <http://www.ietf.org/ietf/IPR/RSA-MD-all> states
that implementations of the MD2, MD4, and MD5 message-digest
algorithms, including implementations derived from the reference
C code in RFC 1319, RFC 1320, and RFC 1321, may be made, used, 
and sold without license from RSA Security for any purpose. 

U.S. National Institute of Standards and Technology (NIST) IPR
<http://www.ietf.org/ietf/IPR/DSA-NIST> states that they have made
the Digital Signature Algorithm (DSA) patent available 
royalty-free to users worldwide. 

Certicom IPR <http://www.ietf.org/ietf/IPR/CERTICOM-ECDSA> states 
that they believe that they have patents issued or pending that 
relate to Elliptic Curve DSA (ECDSA) as follows: point 
compression, public key validation (including domain parameter
validation), and computational techniques.  They are willing to
offer a non-exclusive license under reasonable and 
non-discriminatory terms and conditions, providing the applicant 
provides a similar grant for the applicant's relevant patents
(if any) and respects Certicom's other intellectual property.

Certicom IPR <http://www.ietf.org/ietf/IPR/CERTICOM-SMIME-1>
states that they have U.S. Patent No. 5,933,504 issued regarding 
Diffie-Hellman (D-H) Small Subgroup Attacks.  They are offering 
a royalty-free license for the restricted field of use of 
Ephemeral-Static (E-S) D-H as specified in the S/MIME 
specifications (i.e. RFC 2631).  The Certicom license does
not address fields of use other than E-S D-H.  Other algorithms
require a separate license.  The Certicom license requires 
reciprocal grant to licensee's patents (if any) in same field 
of use.

IBM IPR <http://www.ietf.org/ietf/IPR/IBM-diffie-hellman.html>
states that they have U.S. Patent No. 5,953,420 issued regarding
D-H.  Where there is a necessary dependence upon this patent to
implement the algorithms, IBM will provide a non-exclusive 
license under reasonable and non-discriminatory terms and 
conditions, in accordance with IBM's usual licensing practices.
Russ' personal opinion is that this patent does not apply to the
Ephemeral-Static (E-S) D-H algorithm as described in RFC 2631.

Don Hall IPR <http://www.ietf.org/ietf/IPR/HALL-SMIME> states that
he has U.S. Patent No. 5,126,728 issued regarding Security Labels.
Nonexclusive licenses, on relevant patent claims, will be made 
openly available for a reasonable fee, without discrimination.
Russ' personal opinion is that this patent does not apply to the
security labeling as described in RFC 2634.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Interoperability Matrix - Jim Schaad

Jim briefed that he is still working with the S/MIME Freeware Library
and Microsoft S/MIME v3 implementations to build and process examples
of the features documented in the interoperability matrix for RFCs 
2630 through 2634.  Other organizations that have developed S/MIME v3
capabilities are requested to participate.  If an organization
has already performed tests that fulfill a particular requirement,
then the results should be included in the matrix.  Please submit
input to Jim at [e-mail].

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

CMS and ESS Examples - Paul Hoffman

Paul stated that he had distributed a new release of the "Examples of
S/MIME Messages" I-D <draft-ietf-smime-examples-06.txt>, 25 February 
2001, that includes corrected sample data generated by Getronics
using the SFL.  He stated that the document needs further input and 
testing.  He asked that other organizations that have developed 
S/MIME v3 capabilities should please participate.  He invited people 
to provide comments regarding errors in the document.  He acknowledged
that there are still errors in some of the test data that must be 
fixed.  He stated that since nobody had provided a sample of an 
EnvelopedData using RC2/40 for content encryption using a 
previously-distributed key-encryption key, that he would eliminate
that section from the document.  When Paul stated that nobody had
provided any sample AuthenticatedData objects, Jim Schaad volunteered
to provide those examples.  Chris Bonatti questioned the value of
including AuthenticatedData objects in the document that only Jim
Schaad could build and process.  The consensus was that was better
than nothing.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Symmetric Key Distribution - Sean Turner

Sean stated that he had distributed a new release of the S/MIME
Symmetric Key Distribution I-D, <draft-ietf-smime-symkeydist-03.txt>, 
2 March 2001.  Sean noted that Jim Schaad provided significant 
comments to the symkeydist-02 I-D that Sean incorporated into the 
symkeydist-03 I-D.  

Sean briefed the following changes included in symkeydist-03:
- Reorganized requirements (Each component has mandatory and
    optional support requirements).
- Removed restriction that only Group List (GL) Owner (GLO) is
    allowed on unmanaged lists.
- Added new field to GLRekey to support rekey of all outstanding 
    keys.
- Added ASN.1 module.
- Added text for "Using the Group Key".
- Added date to GLKRefresh to support getting a range of previously
    distributed keys. 
- Modified GLProvideCert and GLUpdateCert so they are the same 
    syntax.
- Removed strict requirement for encrypting outbound messages if 
    inbound messages were encrypted.
- ktri instead of kari RecipientInfo choice.
- Added checks for the GLO and GL member to make sure the GL's 
    certificate was used to sign the response.

Sean stated that he is incorporating comments to symkeydist-03
regarding using the new Certificate Management Messages over 
CMS (CMC) structures.  Also, some object identifiers (OID) need
to be defined.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

X.400 and CMS - Chris Bonatti

Chris presented a briefing regarding the "Transporting S/MIME Objects
in X.400" I-D, <draft-ietf-smime-x400transport-01.txt> and "Securing
X.400 Content with S/MIME" I-D, <draft-ietf-smime-x400wrap-01.txt> 
both distributed in November 2000.  Both drafts are proposed
for the IETF Standards Track.  Paul Hoffman is the primary editor
for both drafts and will be delivering an "02" version of both 
drafts once he has incorporated comments.  

The x400wrap I-D specifies how to protect X.400 content with CMS 
objects.  It is roughly analogous to RFC 2633 and refers to RFC2633
when applicable.  Chris believes that the "02" version will be 
ready for S/MIME working group last call.

The x400transport I-D specifies how to package CMS objects for 
transport by X.400 Message Transfer Agents (MTA).  It is separate
from the X.400 wrapping draft to encourage use of RFC 822/MIME 
content in X.400 communities.  

One outstanding issue is the X.400 Transport of the "certs-only"
format.  RFC 2633 specifies a convention for identifying a message
that contains a "degenerate" SignedData structure that contains no
encapsulated content, but is sent merely for the purpose of 
conveying certificates or CRLs.  The "certs-only" convention was
omitted from the -01 X.400 Transport draft because the RFC 2633
convention was not applicable and it was unclear whether Public Key
Cryptography Standard (PKCS) 10 requests would be used in the X.400
environment.  Discussion with some in the X.400 community yielded
a proposal to identify certs-only messages via the encoded-
information-types (EITs) field in the X.400 envelope.  Chris' 
proposed solution was to add clarifying text to the X.400 
Transport document. This approach was discussed on the mailing 
list and appeared to be acceptable.  

A comment was sent to the mailing list that the "certs-only" 
message was misnamed because it could include certificates and/or
Certificate Revocation Lists (CRL).  Chris made the point that
if the x400transport I-D is changed, then RFC 2633 should also
be changed to be consistent.  He further stated that this is 
a real issue because CRLs are being conveyed in operational 
S/MIME messages today.   

Paul Hoffman expressed his opinion that the name of the message 
should be changed to clarify the contents.  He stated that a 
similar misnomer had created problems in the IPSEC environment
because implementations were not expecting CRLs to be included
in an ASN.1 encoded object and crashed when they were included.

Jim Schaad expressed his concern that we may be setting a 
precedent for defining new S/MIME types for every new type of
S/MIME message that is defined (such as CMC).  Jim asked if the
plan was to define other S/MIME types.

Chris replied that he did not think that it was necessary to 
create a new S/MIME type for every variation of S/MIME message.

Jim asked why it is necessary for certs-only messages.

Chris stated that RFC 2633 defined a different S/MIME type so
that applications would know to process it differently.

Jim stated that S/MIME applications include special processing
rules for some types of S/MIME messages such as signed receipts and
certs-only.  His opinion is that we only need to identify those
messages with special S/MIME types that require special processing.

Chris agreed with Jim's statement and further stated that the 
x400transport I-D should be consistent with RFC 2633 regarding
identification of messages that require special processing.

Russ stated that in X.400, content types are expressed as an OID;
however, MIME uses a structure that permits subtypes.  The X.400
use of an OID does not permit subtypes.

Jim asked if we planned to define OID values for other MIME
subtypes.

Russ pointed out that signed receipts require special 
processing, so they should also have a special X.400 type.

Chris stated that he will draft proposed text regarding the 
certs-only issue for inclusion in the x400transport I-D.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Reuse of Content Encryption Keys - Steve Farrell

Steve presented a briefing regarding the "Reuse of CMS Content
Encryption Keys" I-D, <draft-ietf-smime-rcek-01.txt>, February 2001.
The rcek I-D specifies how to set up a shared secret key using 
asymmetric crypto (using EnvelopedData) and then to re-use 
the content encryption key (CEK) to derive the Key Encryption
Key (KEK) of the next message.  

Steve briefed the changes included in the rcek-01 I-D:
- Key Derivation Function (KDF) changed to use PKCS #5 v2 KDF.
- Removed error attribute.
- Added ASN.1 module.
- Regarding comment that bit-reversal breaks DES parity bits,
    so use byte reversal instead.
- Received comments to use other KDFs such as X9.63/p1363a or
     TLS PRF.  Steve decided to stick with PKCS #5.
- Received comments regarding attribute syntax: Separate vs.
    single attribute.  Steve decided to stick with separate
    attributes.

Russ pointed out that the PKCS #5 ASN.1 syntax uses 1993 ASN.1
features, so Steve must convert the module to use 1988 ASN.1
syntax and include it in the rcek I-D. 

Paul Hoffman asked why others recommended other KDFs. 

Steve stated that he believed that the PKCS #5 KDF is the 
way to go.

Simon Blake-Wilson stated that he believes that the X9.63 KDF
is more appropriate and efficient.  They are planning to use
S/MIME on a wireless device using scripts so efficiency is
important to them.

Steve disputed the statement that the X9.63 KDF is 
significantly more efficient than the PKCS #5 KDF.

Steve briefed that he still needs to add the following:
- Security consideration documenting the scenario in 
    which msg2 is sent to subset of msg1.
- Text describing combinations of attributes (sent 
    new "conformance" text to list).
- More motivation and "when-to-use" text.
- Security considerations describing flip-flop issue
    (will add text from list).
- Needs OIDs for attributes.
- "Same" algorithms (Text on list)
- CEKMaxDecrypts default & max (default: 1, max: 2^32)
- Comment ASN.1 module

Russ conducted a straw poll of the meeting attendees to obtain 
their opinion regarding the following options for the rcek KDF: 
1) X9.63/P1363a  
2) TLS
3) PKCS #5
There were 3 votes for option 1, no votes for option 2 and
4 votes for option 3.

Russ recommended that rcek should continue to use PKCS #5 KDF 
unless somebody could present a good reason for using another KDF.

Russ asked that people examine the aforementioned byte-reversal
issue.
   
Russ stated that the last call period would be re-started
because of the magnitude of the changes.   

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

AES and RSA-OAEP in CMS - Jim Schaad

Jim presented a briefing regarding the "Use of the Advanced 
Encryption Algorithm in CMS" (aes-alg) I-D.  The I-D specifies how 
to incorporate the Advanced Encryption Standard (AES) into CMS as 
an additional algorithm for symmetric encryption.  Jim stated that
the next version of the aes-alg document will also specify how to 
incorporate the RFC 2437 PKCS #1 v2.0 Optimal Asymmetric Encryption
Padding (RSAES-OAEP) key transport method of key management into CMS
as an additional algorithm.  The "Use of the RSAES-OAEP Key Transport 
Algorithm in CMS" I-D will be eliminated because the information will
be included in the aes-alg I-D.  The aes-alg I-D will describe the
conventions for using the RSAES-OAEP key transport algorithm and AES 
content encryption algorithm with the CMS enveloped-data, 
encrypted-data and authenticated-data content types.  

Jim stated that the S/MIME v3 specifications will be written to state
that compliant implementations will use RSAES-OAEP (rather than 
PKCS #1 v1.5) as the key transport algorithm when AES is used as the
content encryption algorithm.

Jim noted that the aes-alg I-D does not include an AES key wrap 
algorithm, but that he expects that will be provided by July 2001.
He is still waiting for input from NIST which should be provided 
during June or July 2001.
 
Jim noted that he would like to add signature algorithms for
use with SHA-256 to the document.  This is dependent on the 
following events:
- PKCS #1 v2.1 Probabilistic Signature Scheme (PSS) being 
    standardized and OIDs issued
- SHA-256 being standardized
- DSA-SHA-256 Key sizes and OIDs being issued

Tim Polk stated that NIST is working on a DSA specification for
use with SHA-256.  They are discussing the use of PSS/RSA with 
SHA-256.  He believes that they will have a SHA-256/PSS 
specification ready before August 2001.

Simon Blake-Wilson stated that he was concerned that the formats
of the certificates containing RSA public keys for use with 
RSA PKCS #1 v1.5 and RSAES-OAEP are identical.  He was trying 
to make the point that it is good cryptographic practice to
employ a given key pair in only one scheme.  This avoids the risk
that vulnerability in one scheme may compromise the security 
of the other, and may be essential to maintain provable security.
For example, RSAES-OAEP by itself would resist attack, but an 
opponent could exploit a weakness in the implementation of 
RSAES-PKCS #1 v1.5 to recover messages encrypted with either
scheme.  There was much discussion regarding this point.  

Russ Housley pointed out RSA is working to ensure that the RSA
algorithms are consistently specified in the various documents.

Russ recommended that the strengthened key management be 
specified in one I-D and DSA in another. 
 
Tim Polk stated that the PKIX working group will be specifying
how to sign certificates using the new algorithms.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Elliptic Curve Cryptography (ECC) - Simon Blake-Wilson

Simon presented a briefing regarding the "Use of ECC Algorithms in
CMS" I-D, <draft-ietf-smime-ecc-03.txt>, 2 March 2001.  He briefed
that ECC may offer savings in terms of bandwidth, computation, and
storage.  He stated that ECC savings may increase as key sizes 
increase.  

Simon briefed that EC-based algorithms are documented in the 
following specifications:
- Elliptic Curve Diffie-Hellman (ECDH) (from draft ANSI X9.63)
- ECDSA (from ANSI X9.62)
- ECMQV (from draft ANSI X9.63)
- Equivalent specifications in FIPS 186-2, IEEE P1363, SEC 1

Simon briefed that EC-based algorithms can be used with CMS
as follows:
- SignedData using ECDSA
- EnvelopedData using Ephemeral-Static ECDH
- EnvelopedData and AuthenticatedData using 1-pass ECMQV

Notes regarding ECC I-D:
- SignedData provides message digest, ECDSA starts with
   the message.
- Key derivation function uses X9.63.
- AuthenticatedData and multiple recipients.
- Efficiency for AuthenticatedData.
- Key wrap for AuthenticatedData.

To promote interoperability, the ECC I-D documents the
following:
- Recommended algorithms
- Recommended curves
- Use of SMIMECapabilities signed attribute
- Examples

Simon proposed the following plan for the ECC I-D:
- address any comments from meeting
- update ECDH/ECMQV reference?
- issue updated draft
- submit for WG last call

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Mandatory to Implement Algorithms - Russ Housley

Russ briefed that the PKIX WG is not going to select a mandatory to
implement algorithm for certificates, so the S/MIME WG is free to
pick a single signature algorithm for certificates and messages.

Russ reviewed the straw poll conducted at the December 2000 S/MIME
WG meeting which asked attendees of their opinion regarding 
supporting two mandatory-to-implement signature algorithm: DSA 
and RSA (PKCS #1 v1.5).  Russ was concerned about the proposal to
mandate that all implementations must sign using both of these
signature algorithms because their key generation processes
are very different.  He proposed that implementations must be 
able to verify signatures on certificates and messages 
using both the DSA and RSA (PKCS #1 v1.5) signature 
algorithms; however, implementations are only required to 
generate signatures on messages using at least one of the 
signature algorithms. 

Tim Polk stated his support for Russ' proposal because it may be 
practical for implementations that use smart cards to only implement
a single signing algorithm due to the limitations of the smart card
token.

Russ conducted a straw poll of the meeting attendees to obtain 
their opinion regarding the following options for the "MUST
implement" signature algorithm: 
1) sign and verify using both PKCS#1 v1.5 RSA and DSA
2) sign using one algorithm, verify using both (i.e. Russ' proposal)
An overwhelming majority of the meeting attendees voted for option 2. 

Al Arsenault asked if RSA OAEP should be used instead of 
RSA PKCS #1 v1.5.

Russ stated that RSA OAEP had been proposed at previous meetings 
and on the mail list, but was rejected by many implementers.  He noted 
that Eric Rescorla had posted the "Preventing the Million Message 
Attack on CMS" on the mail list on 18 March 2001.  Concerns have been
expressed regarding the use of RSA PKCS#1 v1.5 by automated messaging
applications such as a Mail List Agent.  Eric's document describes the
concerns regarding RSA PKCS#1 v1.5 and some possible countermeasures. 

John Pawling asked if the change to use RSA PKCS#1 v1.5 as the 
mandatory to implement key management algorithm was dependent on the
acceptance of the "Preventing the Million Message Attack on CMS" I-D.
Russ answered that as long as the work was progressing that the change
could be made (similar to RFC 2631 and the Small Subgroup Attack).

Paul Hoffman asked if the change in the algorithms would case the
S/MIME version number to change (ex: v3.1).  John Pawling made the
point that the CMS ASN.1 syntax is not changing, just the algorithms
used with that syntax.  He further stated that the algorithms in an
instance of a CMS object are clearly indicated by OIDs populated in 
that object, so a version number change is not required.  Russ agreed
and made the point that the RFCs would change, but the S/MIME version
number would still be 3.  Nobody disagreed with Russ.  

Russ also stated that he believes that the algorithm information 
should be separated from the CMS specification into a separate RFC
as has been done with the new PKIX specifications.  Nobody disagreed
with Russ.  

In summary, the meeting attendees overwhelmingly agreed
on the following set of mandatory to implement algorithms:  
Signature: DSA and RSA (PKCS #1 v1.5) as per Russ' proposal
Message digest: SHA-1
Key Management: RSA (PKCS #1 v1.5)
Encryption: Triple-DES

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

S/MIME Freeware Library (SFL) - John Pawling

John briefed regarding the SFL which is a freeware implementation
of RFCs 2630 and 2634 developed by Getronics Government Solutions.
The SFL can be used with the Crypto++ freeware library to implement
RFC 2631.  The SFL provides functions to support use of RFCs 2632 
and 2633.  It has been tested on the RedHat Linux, Windows NT/98/00 
and Solaris 2.7 operating systems.  The SFL maximizes crypto 
algorithm independence.  It has been used with the RSA BSAFE v4.2,
Crypto++ v3.2, Fortezza CI and SPYRUS SPEX/ libraries.  Getronics
has developed the capability for the SFL to use any security
library that provides a PKCS #11 interface.

Getronics has used the SFL to perform a significant amount of S/MIME
v3 interop testing.  Getronics tested the majority of features
in RFCs 2630, 2631 and 2634 as well as some of the features in RFCs
2632 and 2633.  Getronics used the SFL to successfully process and
produce the majority of features documented in "Examples of S/MIME
Messages".  SFL-generated data was included in the Examples I-D
such as: signed receipts, countersignatures, security labels, 
equivalent security labels, mail list information and signing 
certificate attributes.

S/MIME v3 interoperability testing between the SFL and Microsoft 
successfully tested almost all CMS/ESS features using mandatory,
RSA and Fortezza algorithm suites.  For example, successful signed
receipt interoperability testing was performed between the SFL 
and Microsoft.  Getronics verified that the SFL can produce and 
process the majority of features documented in Jim Schaad's 
S/MIME v3 interoperability matrix.  Complete test drivers and test
data are available with the SFL.

Getronics delivered the v1.9 SFL in February 2001 that included 
improved PKCS #11 capabilities (tested with GemPlus, DataKey
and Litronic PKCS #11 libraries).  It also included AES content
encryption (as per aes-alg-00) and key wrap based on CMS 
Triple-DES key wrap algorithm (this may need to be changed when
the AES key wrap algorithm is included in the aes-alg I-D).  It
also included an Enhanced SNACC library that increases 
performance and decreases memory usage.  

John provided information regarding the Certificate Management 
Library (CML) that is a freeware implementation of X.509 v3
certification path verification as specified in the 2000 X.509
Recommendation (except Delta CRLs are not implemented).  
The CML: validates X.509 certification paths and CRLs; provides
local certificate/CRL storage functions; and provides remote
directory retrieval via LDAP.  The CML complies with the majority 
of the RFC 2459 requirements.  In February 2001, Getronics delivered
the v1.9 CML enhanced to support the 2000 X.509 certificate policy
processing requirements.

John provided information regarding the Getronics-developed 
Access Control Library (ACL) that provides Rule Based Access 
Control using security labels and authorizations conveyed in either 
X.509 Attribute or public key certificates.  He also discussed the
Getronics Enhanced SNACC ASN.1 library that implements the 
Distinguished Encoding Rules (DER). 

For all of the Getronics freeware libraries, unencumbered source
code is freely available to all.  Getronics freeware can be used
as part of applications without paying any royalties or licensing
fees.  There is a public license associated with each Getronics
freeware library.

The Getronics freeware libraries are available at:
SFL: <http://www.getronicsgov.com/hot/sfl_home.htm>
CML: <http://www.getronicsgov.com/hot/cml_home.htm>
ACL: <http://www.getronicsgov.com/hot/acl_home.htm>
SNACC: <http://www.getronicsgov.com/hot/snacc_home.htm>

The Internet Mail Consortium (IMC) has established SFL, CML and
Enhanced SNACC mail lists.  John pointed out that SFL/CML/Enhanced
SNACC messages should be sent to the IMC lists and should not be
sent to the IETF mail lists.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Wrap Up - Russ Housley

Russ asked if there were any other issues to discuss.  The meeting
attendees were silent.

Meeting adjourned.



Received: by above.proper.com (8.9.3/8.9.3) id GAA24756 for ietf-smime-bks; Wed, 4 Apr 2001 06:19:05 -0700 (PDT)
Received: from mail.ca.certicom.com (ip6.certicom.com [209.121.99.6] (may be forged)) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA24752 for <[e-mail]>; Wed, 4 Apr 2001 06:19:04 -0700 (PDT)
Received: from smtpmail.certicom.com (domino2.certicom.com [10.0.1.25]) by mail.ca.certicom.com (8.9.3/8.9.3) with SMTP id JAA28970 for <[e-mail]>; Wed, 4 Apr 2001 09:12:40 -0400 (EDT)
Received: by smtpmail.certicom.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256A24.00491C14 ; Wed, 4 Apr 2001 09:18:33 -0400
X-Lotus-FromDomain: CERTICOM
From: "Simon Blake-Wilson" <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 4 Apr 2001 09:15:18 -0400
Subject: Certicom IPR statement and license
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi folks,

The updated Certicom IPR statement and license that Russ referred to in
Minneapolis
has now been posted on the IETF web page ... the urls are:

http://www.ietf.org/ietf/IPR/CERTICOM-SMIME-1
http://www.ietf.org/ietf/IPR/certicom_smime_license.pdf

linked from:

http://www.ietf.org/ipr.html

Best regards. Simon

S. Blake-Wilson
Certicom Corp.




Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id SAA17587 for ietf-smime-bks; Tue, 3 Apr 2001 18:26:45 -0700 (PDT)
Received: from femail12.sdc1.sfba.home.com (femail12.sdc1.sfba.home.com [24.0.95.108]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA17583 for <[e-mail]>; Tue, 3 Apr 2001 18:26:44 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail12.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010404012643.GYCZ3930.femail12.sdc1.sfba.home.com@revelation>; Tue, 3 Apr 2001 18:26:43 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>, <IETF-Announce:>
Cc: <[e-mail]>
Subject: RE: Last Call: Password-based Encryption for S/MIME to Proposed Standard
Date: Tue, 3 Apr 2001 18:29:13 -0700
Message-ID: <001e01c0bca6$a8c21aa0$[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 CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: 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>

Comments on this draft:

1.  Title:  I suggest that "Password-based Encryption for CMS" is a better
title. [Comment made in working group last call]

2.  Section 1: Paragraph 2:  The format of the messages are described using
1988 not 1994 ASN.  Please update this reference.

3. Section 1.2.1: Paragraph 1: The phrase "user-supplied password or
previously agreed-upon key" is somewhat misleading.  KEK is the generally
used agreed-upon key method for key managment.  Please delete the phrase "or
previously agreed-upon key".  (Ditto for all subsequent references.)

4.  Section 1.2.1: In the event that two password recipient info's are
present, how do I determine which is the one I am to use?

5.  Section 1.2.1: Paragraph keyEncryptionAlgorithm: This field identifies a
key-encryption not a content-encryption algorithm.  Please update.

6.  Section 1.2.1: Paragraph keyDerivationAlgorithm: Please justfy why this
is optional.  The same behavior could be obtained from the KEK with an empty
keyIdentifier field.  I don't think this generally useful because as with
question 4 above how do you determine the correct one in the event that
multiple of these exist in the structure. [Comment made in working group
last call.]

7.  Section 2.1: Paragraph 2:  You cannot place a MUST on CMS
implementations.  Please change to "Conforming implementations".

8.  Section 2.2 & 2.3:  You have Key Encryption algorithms and Symmetric Key
Encryption algorithms.  I don't understand the difference between these two
groups as they both appear to be using symmetric keys, take a KEK and
encrypt a CEK.  The only difference appears to be that the first are simple
encrytion algorithms and the second are complex ones.

9.  Section 2.2:  What is KSG?  This is not expanded anyplace.

10. Section 2.2:  Why is Triple-DES/CBC a MUST algorithm.  This appears to
be reasonable for content encryption but is not a good idea for key
encryption.

11. Section 2.3.1: Item 4:  Suggest you change the start of the text to
"Append random padding to make the CEK data block a multiple of the KEK
block length.  Enough padding must be added to ensure that the resulting
data block is atleast two KEK blocks long. (The..."

12.  Section 2.3.3: unwrap Item 2:  This does not appear to agree with the
algorithm in section 2.3.2.  Should it not be "Set the IV to the decrypted
content, decrypt the first 8 bytes."?

13.  Section 2.2: I am having a problem with what you are using for the
KeyEncryptionAlgorithm.  I think that you need to use something other than
the standard content-encryption algorithm OIDs in this location due to the
fact that you are adding additional processing in the form of the wrapping
algorithm.  I think that this issue alone is a killer for this document as
it is presently set out.

14.  Section 2.2: It is still my belief that the key wrap algorithm
presented as part of RFC2460 should be the MUST key wrap algorithm (i.e.
id-alg-CMS3DESwrap).  The CMS version will be implemented in software for
CMS compatilibity and in all likely hood will also be done in hardware as
well if KEK encryption ever becomes real common place. (For use with S/MIME
symmetric key mailing lists if nothing else.) While I don't object to your
offering a second key wrap algorithm I don't see a strong benifit for it
over the already existing version in CMS. [Comment made in working group
last call.]

15.  Appendix A: Imports statement is syntaxically incorrect. (Probably also
wrong for Appendix B.)

16.  Appendix A: Missing definitions for the imported items -- they can't be
imported from an ASN.1 1994 module.  They need to be copied here not
imported.

17.  Appendix B: Do not re-use the same module numbers for both the 1994 and
1988 versions of the ASN modules.



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of The IESG
> Sent: Tuesday, April 03, 2001 11:46 AM
> To: IETF-Announce:
> Cc: [e-mail]
> Subject: Last Call: Password-based Encryption for S/MIME to Proposed
> Standard
>
>
>
> The IESG has received a request from the S/MIME Mail Security Working
> Group to consider Password-based Encryption for S/MIME
> <draft-ietf-smime-password-03.txt> as a Proposed Standard.
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [e-mail] or [e-mail] mailing lists by April 17, 2001.
>
> Files can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-smime-password-03.txt
>
>
>



Received: by above.proper.com (8.9.3/8.9.3) id LAA25279 for ietf-smime-bks; Tue, 3 Apr 2001 11:46:28 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA25275 for <[e-mail]>; Tue, 3 Apr 2001 11:46:26 -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 OAA12849; Tue, 3 Apr 2001 14:46:26 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: [e-mail]
From: The IESG <[e-mail]>
SUBJECT: Last Call: Password-based Encryption for S/MIME to Proposed Standard
Reply-to: [e-mail]
Date: Tue, 03 Apr 2001 14:46:26 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has received a request from the S/MIME Mail Security Working
Group to consider Password-based Encryption for S/MIME
<draft-ietf-smime-password-03.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by April 17, 2001.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-smime-password-03.txt




Received: by above.proper.com (8.9.3/8.9.3) id IAA25880 for ietf-smime-bks; Mon, 2 Apr 2001 08:45:07 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id IAA25867 for <[e-mail]>; Mon, 2 Apr 2001 08:45:05 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 2 Apr 2001 15:42:43 UT
Received: from HOUSLEY-LAP.rsasecurity.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA28452 for <[e-mail]>; Mon, 2 Apr 2001 11:45:03 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 02 Apr 2001 11:37:04 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: WG Last Call:draft-ietf-smime-ecc-04.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The ECC document is ready for S/MIME WG Last Call.  This document is 
intended fro the standards track.  Please post all comments by 17 April 2001.

	Title		: Use of ECC Algorithms in CMS
	Author(s)	: S. Blake-Wilson, D. Brown, P. Lambert
	Filename	: draft-ietf-smime-ecc-04.txt
	Pages		: 16
	Date		: 30-Mar-01
	



Received: by above.proper.com (8.9.3/8.9.3) id EAA05107 for ietf-smime-bks; Mon, 2 Apr 2001 04:17:38 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA05103 for <[e-mail]>; Mon, 2 Apr 2001 04:17:36 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00383; Mon, 2 Apr 2001 07:17:36 -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-ecc-04.txt
Date: Mon, 02 Apr 2001 07:17:35 -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		: Use of ECC Algorithms in CMS
	Author(s)	: S. Blake-Wilson, D. Brown, P. Lambert
	Filename	: draft-ietf-smime-ecc-04.txt
	Pages		: 16
	Date		: 30-Mar-01
	
This document describes how to use Elliptic Curve Cryptography
(ECC) public-key algorithms in the Cryptographic Message Syntax
(CMS).  The ECC algorithms support the creation of digital
signatures and the exchange of keys to encrypt or authenticate
content.  The definition of the algorithm processing is based on
the ANSI X9.62 standard and the ANSI X9.63 draft, developed by the
ANSI X9F1 working group.

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

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.9.3/8.9.3) id QAA04750 for ietf-smime-bks; Sun, 1 Apr 2001 16:11:39 -0700 (PDT)
Received: from server.village.com.ar (host069098.arnet.net.ar [200.45.69.98]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA04730 for <[e-mail]>; Sun, 1 Apr 2001 16:11:35 -0700 (PDT)
From: [e-mail]
Received: from 44mexi7server42 ([127.0.0.1]) by server.village.com.ar (8.9.3/8.9.3) with SMTP id UAA18171 for [e-mail]; Sun, 1 Apr 2001 20:26:33 -0400
Date: Sun, 1 Apr 2001 20:26:33 -0400
Message-Id: <[e-mail]>
To: <[e-mail]>
Subject: ADV: Top Search Engine Rankings
MIME-Version: 1.0
Content-Type: text/plain; charset=unknown-8bit
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>

Removal instructions below.

I saw your listing on the internet.

I work for a company that specializes
in getting clients web sites listed
as close to the top of the major
search engines as possible.

Our fee is only $29.95 per month to
submit your site at least twice a
month to over 350 search engines
and directories.

To get started and put your web site
in the fast lane, call our toll free
number below.


Mike Bender
888-532-8842


To be removed call: 888-800-6339 X1377