RE: nonRepudiation key usage in SSL and S/MIME

["Bob Jueneman" <[e-mail]>]

Recently, we have been having some discussion regarding 
Nonrepudiation on the cert-talk list, and I have been taking the 
position that the Nonrepudiation key usage bit should be reserved
for those key pairs that are used exclusively to indicate the user's
conscious and willing intent to be legally bound by what is being 
signed.

Although I have only been watching the S/MIME list with one eye
open, so to speak, and haven't even had the time to download 
the various specs, a potential problem did occur to me.  

Is it possible, and should it be the norm, for the automatic reply
to confirm receipt to be signed with a completely different certificate
than is used to sign legally binding mail?  How is this handled?

Bob

>> William Whyte <[e-mail]> 04/30/99 05:50AM >>>
Hi Bob,

> (S/MIME v3 may raise an interesting issue here that I ought to go
> check.  Since it provides the ability to have a signed acknowledgment
> of a message's receipt, I would hope that the certificate used for that
> acknowledgment can be different from the one used to actually
> and consciously sign are replay.)

Pleased to see someone else bring this up; I've just been writing
some documentation on our new S/MIME 3 toolkit, from a position of
relative unfamiliarity with the ESS services, and this really stuck
out like a sore thumb for me. I think it may have been an error to
put the automatic generation of receipts as a MUST without addressing
this problem. It may be worth raising on the list, despite the late
stage we're at in the proceedings.

Cheers,

WIlliam

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[e-mail]
1-801-861-7387




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA07284 for ietf-smime-bks; Fri, 30 Apr 1999 12:36:04 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA07280 for <[e-mail]>; Fri, 30 Apr 1999 12:36:03 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 30 Apr 1999 13:37:18 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Fri, 30 Apr 1999 13:37:05 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, "<"<[e-mail]>
Subject: RE: nonRepudiation key usage in SSL and S/MIME
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id MAA07281
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Recently, we have been having some discussion regarding 
Nonrepudiation on the cert-talk list, and I have been taking the 
position that the Nonrepudiation key usage bit should be reserved
for those key pairs that are used exclusively to indicate the user's
conscious and willing intent to be legally bound by what is being 
signed.

Although I have only been watching the S/MIME list with one eye
open, so to speak, and haven't even had the time to download 
the various specs, a potential problem did occur to me.  

Is it possible, and should it be the norm, for the automatic reply
to confirm receipt to be signed with a completely different certificate
than is used to sign legally binding mail?  How is this handled?

Bob

>> William Whyte <[e-mail]> 04/30/99 05:50AM >>>
Hi Bob,

> (S/MIME v3 may raise an interesting issue here that I ought to go
> check.  Since it provides the ability to have a signed acknowledgment
> of a message's receipt, I would hope that the certificate used for that
> acknowledgment can be different from the one used to actually
> and consciously sign are replay.)

Pleased to see someone else bring this up; I've just been writing
some documentation on our new S/MIME 3 toolkit, from a position of
relative unfamiliarity with the ESS services, and this really stuck
out like a sore thumb for me. I think it may have been an error to
put the automatic generation of receipts as a MUST without addressing
this problem. It may be worth raising on the list, despite the late
stage we're at in the proceedings.

Cheers,

WIlliam

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[e-mail]
1-801-861-7387



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA21174 for ietf-smime-bks; Thu, 29 Apr 1999 21:36:02 -0700 (PDT)
Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA21164 for <[e-mail]>; Thu, 29 Apr 1999 21:36:01 -0700 (PDT)
Received: by dfssl with Internet Mail Service (5.5.2580.0) id <JYTLMPL1>; Thu, 29 Apr 1999 21:37:03 -0700
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5ED0@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "Ietf-Smime (E-mail)" <[e-mail]>, "John Pawling (E-mail)" <[e-mail]>
Subject: Comments on cmskea
Date: Thu, 29 Apr 1999 21:37:04 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2580.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John,

I am having a big problem with the amount of overload going on for the the
OID id-keyExchangeAlgorithm.  It appears to be used in three unique
locations in encoding an encrypted message and has different meanings and
two different set of parameters.


1.  id-keyExchangeAlgorithm is used in a certificate to identify the
asymmetric algorithm.  The parameters in this case are an OCTET STRING
identifing the group parameters for the key.

2.  id-keyExchangeAlgorithm is used in the KeyAgreementRecipientInfo
keyEncryptionAlgorithm field.  In this case the parameters is
KeyWrapAlgorithm (using id-fortezzaWrap80 as the algorithm).

3.  id-keyExchangeAlgorithm is used in KEKRecipientInfo
keyEncryptionAlgorithm field.  In this case a completely different algorithm
is being referenced and again the parameters are KeyWrapAlgorithm.


I strong suggest that we change this as follows:

1.  id-keyExchangeAlgorithm is used in certificate w/parameters and in
KeyAgreementRecipeintInfo w/o parameters.

2.  id-fortezzaWrap80 is used in KEKRecipientInfo for the KEK algorithm
again w/o parameters are they are not needed.

This should work unless we belive that there would ever be a different
content encryption algorithm for KEA.


jim



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA07157 for ietf-smime-bks; Tue, 27 Apr 1999 14:11:29 -0700 (PDT)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA07153 for <[e-mail]>; Tue, 27 Apr 1999 14:11:27 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id OAA26563; Tue, 27 Apr 1999 14:11:18 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
X-Priority: 1 (Highest)
Date: Tue, 27 Apr 1999 17:12:07 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Ready for Publication as RFCs
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeff:

The changes requested by the IESG are finished.  We are now ready for the
RFC Editor.

The documents are:

	draft-ietf-smime-cert-08.txt
	draft-ietf-smime-cms-13.txt
	draft-ietf-smime-ess-12.txt
	draft-ietf-smime-msg-08.txt
	draft-ietf-smime-x942-07.txt 

Russ 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA00939 for ietf-smime-bks; Tue, 27 Apr 1999 10:31:27 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA00935 for <[e-mail]>; Tue, 27 Apr 1999 10:31: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 NAA23833; Tue, 27 Apr 1999 13:31:23 -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-msg-08.txt
Date: Tue, 27 Apr 1999 13:31:22 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: S/MIME Version 3 Message Specification
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-msg-08.txt
	Pages		: 27
	Date		: 26-Apr-99
	
S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a
consistent way to send and receive secure MIME data. Based on the
popular Internet MIME standard, S/MIME provides the following
cryptographic security services for electronic messaging applications:
authentication, message integrity and non-repudiation of origin (using
digital signatures) and privacy and data security (using encryption).
 
S/MIME can be used by traditional mail user agents (MUAs) to add
cryptographic security services to mail that is sent, and to interpret
cryptographic security services in mail that is received. However,
S/MIME is not restricted to mail; it can be used with any transport
mechanism that transports MIME data, such as HTTP. As such, S/MIME
takes advantage of the object-based features of MIME and allows secure
messages to be exchanged in mixed-transport systems.
 
Further, S/MIME can be used in automated message transfer agents that
use cryptographic security services that do not require any human
intervention, such as the signing of software-generated documents and
the encryption of FAX messages sent over the Internet.

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

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29646 for ietf-smime-bks; Tue, 27 Apr 1999 09:53:47 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29642 for <[e-mail]>; Tue, 27 Apr 1999 09:53: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 MAA21385; Tue, 27 Apr 1999 12:54:43 -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-cert-08.txt
Date: Tue, 27 Apr 1999 12:54:42 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29641 for ietf-smime-bks; Tue, 27 Apr 1999 09:53:34 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29637 for <[e-mail]>; Tue, 27 Apr 1999 09:53:32 -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 MAA21362; Tue, 27 Apr 1999 12:54:29 -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-cms-13.txt
Date: Tue, 27 Apr 1999 12:54:29 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
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-cms-13.txt
	Pages		: 59
	Date		: 23-Apr-99
	
This document describes the Cryptographic Message Syntax.  This
   syntax is used to digitally sign, digest, authenticate, or encrypt
   arbitrary messages.
 
   The Cryptographic Message Syntax is derived from PKCS #7 version 1.5
   as specified in RFC 2315 [PKCS#7].  Wherever possible, backward
   compatibility is preserved; however, changes were necessary to
   accommodate attribute certificate transfer and key agreement
   techniques for key management.
 
   This draft is being discussed on the 'ietf-smime' mailing list.  To
   join the list, send a message to <[e-mail]> with
   the single word 'subscribe' in the body of the message.  Also, there
   is a Web site for the mailing list at <http://www.imc.org/ietf-
   smime/>.

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

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29589 for ietf-smime-bks; Mon, 19 Apr 1999 09:22:55 -0700 (PDT)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29584 for <[e-mail]>; Mon, 19 Apr 1999 09:22:49 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id JAA27737; Mon, 19 Apr 1999 09:21:48 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 19 Apr 1999 12:17:55 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: What is the ToBeSignedData for signedData(pkcs#7) in SMIME system of Netscape Communicator 4.04?
Cc: "ietf(about smime)" <[e-mail]>
In-Reply-To: <002201be8950$b81bc810$[e-mail]>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<html>
This is not the correct mail list for discussing this problem.&nbsp; This
mail list is for the discussion of S/MIME v3 standards.&nbsp; Please take
this discussion to the correct list.<br>
<br>
Russ<br>
<br>
<br>
At 12:04 PM 4/18/99 +0800, [e-mail] wrote: <br>
<font face="arial" size=2><blockquote type=cite cite>Hi,</font><br>
Recently, we implement SMIME system.<br>
We use Netscape Communicator 4.04 to test our implemention.<br>
Then we encounter the following problem.<br>
We decrypt the SignedData(We get from smime mail of Netscape<br>
Communicator 4.04).<br>
We find the hash value is different from the hash value of the 
field<br>
unauthenticatedAttributes(contained in SingnerInfo).<br>
We are sure that our decrypted value is correct since it satisfy 
the<br>
formate of PKCS#1.<br>
We try hash every paragraph in SMIME mail.<br>
One of our hash values is same as hash value in the field<br>
unauthenticatedAttributes.<br>
But no one is same as our decrypted value.<br>
&nbsp;<br>
<font face="arial" size=2>Our environment: Netscape Communicator 4.04,
Trial Class 1 VeriSign<br>
Digital ID.</font><br>
&nbsp;<br>
<font face="arial" size=2>Thanks for your help.</font><br>
&nbsp;<br>
&nbsp;</blockquote><br>
</html>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA27797 for ietf-smime-bks; Mon, 19 Apr 1999 07:00:02 -0700 (PDT)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA27789 for <[e-mail]>; Mon, 19 Apr 1999 06:59:56 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id GAA25219 for <[e-mail]>; Mon, 19 Apr 1999 06:59:28 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 19 Apr 1999 09:58:39 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: 45th IETF - Oslo, Norway: Agenda Requests
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Meeting Dates: July 12-16, 1999

I have requested one two hour slot in Oslo.  Please send me agenda topics.

Russ


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA27703 for ietf-smime-bks; Mon, 19 Apr 1999 06:51:07 -0700 (PDT)
Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA27699 for <[e-mail]>; Mon, 19 Apr 1999 06:51:06 -0700 (PDT)
Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id JAA12533; Mon, 19 Apr 1999 09:58:19 -0400 (EDT)
Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id JAA20559; Mon, 19 Apr 1999 09:55:19 -0400
Date: Mon, 19 Apr 1999 09:55:19 -0400
Message-Id: <[e-mail]>
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: [e-mail]
From: [e-mail] (John Pawling)
Subject: Revised 19990317 S/MIME WG Mtg Minutes
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

This message includes the 17 March 1999 S/MIME WG meeting minutes 
revised to include Denis Pinkas' comment.  The changes between the 
original minutes submitted on 26 March 1999 and these revised 
minutes are as follows:

1) Replaced the following paragraph:

OLD:
"Russ asked if there were any other unresolved issued regarding CMS. 
Denis Pinkas stated that he believes that CMS should specify how key 
validation is performed.  He is especially concerned with the case in 
which multiple Certification Authority (CA) certificates contain the 
same public key. A vast majority of the meeting attendees decided that 
the PKIX X.509 Certificate and CRL Profile (RFC2459) (referred to by 
the CERT I-D) specifies how key validation is performed and that CMS 
should not replicate that information."

NEW:
"Russ stated that Denis Pinkas submitted comments to the S/MIME WG 
mail list requesting additional text in CMS to explain how the correct
signer's public key used to perform signature verification is
obtained.  Russ stated that he would work with Denis to derive the 
exact words to be proposed for addition to CMS and then the S/MIME WG 
members would be given the opportunity to review the proposed 
changes."

2) Spelled out CA and RFC2459 in the revised minutes where each term
is first used.

These changes result in the following revised minutes:

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

This message includes the minutes of the IETF S/MIME Working Group 
(WG) meeting held on 17 March 1999 in Minneapolis, MN, USA. These 
minutes were coordinated with the briefing presenters.  All briefing 
slides are stored at: ftp://ftp.ietf.org/ietf/smime/.  Reported by
John Pawling.


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

Introductions - Russ Housley
 
Russ reviewed the agenda.  Nobody objected to the agenda.


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

CMS Draft Discussion - Russ Housley

Russ presented the status of the February 1999 Cryptographic Message 
Syntax (CMS-11) Internet-Draft (I-D).  CMS-11 is in IETF Last Call.  
The majority of the comments received since the last meeting have 
focused on Section 12. (This is the section on algorithms and key 
wrapping support.)  CMS-11 includes new key wrap algorithms that 
resolve the issues raised on the S/MIME WG mail list regarding 
possible cryptographic vulnerabilities such as Burt Kaliski's comments 
regarding the "birthday attack". The completion of CMS depends on the 
Diffie-Hellman (D-H) Key Agreement Method I-D (X9.42 I-D).

Russ reviewed the highlights of the CMS-11 Key Wrapping Algorithm 
sections.  CMS-11 documents a mandatory-to-implement key wrapping 
algorithm that describes the process of wrapping a Triple-DES content 
encryption key (CEK) with a Triple-DES key encryption key (KEK). It 
documents another (optional) key wrapping algorithm that describes the 
process of wrapping an RC2 CEK with an RC2 KEK.  Each key wrapping 
algorithm includes instructions for key checksum, key wrap and key 
unwrap.  

The CMS-11 Checksum Algorithm is used to provide a CEK integrity check 
value.  The algorithm is:
   1.  Compute a 20 octet SHA-1 message digest on the CEK.
   2.  Use the most significant (first) eight octets of the message 
       digest value as the checksum value.

The Triple-DES key wrap algorithm encrypts a Triple-DES CEK with a 
Triple-DES KEK.  The CMS-11 Triple-DES key wrap algorithm is:
   1.  Set odd parity for each of the DES key octets comprising the 
       CEK, call the result CEK.
   2.  Compute an 8 octet key checksum value on CEK as described 
       above, call the result ICV.
   3.  Let CEKICV = CEK || ICV.
   4.  Generate 8 octets at random, call the result IV.
   5.  Encrypt CEKICV in CBC mode using the key-encryption key.  Use 
       the random value generated in the previous step as the 
       initialization vector (IV).  Call the ciphertext TEMP1.
   6.  Let TEMP2 = IV || TEMP1.
   7.  Reverse the order of the octets in TEMP2.  That is, the most 
       significant (first) octet is swapped with the least significant 
       (last) octet, and so on.  Call the result TEMP3.
   8.  Encrypt TEMP3 in CBC mode using the key-encryption key.  Use IV 
       of 0x4adda22c79e82105.  The ciphertext is 40 octets long.

The Triple-DES key unwrap algorithm decrypts a Triple-DES CEK using a 
Triple-DES KEK.  The CMS-11 DES key unwrap algorithm is:
   1.  If the wrapped CEK is not 40 octets, then error.
   2.  Decrypt the wrapped CEK in CBC mode using the KEK.  Use an IV 
       of 0x4adda22c79e82105.  Call the output TEMP3.
   3.  Reverse the order of the octets in TEMP3.  That is, the most 
       significant (first) octet is swapped with the least significant 
       (last) octet, and so on.  Call the result TEMP2.
   4.  Decompose the TEMP2 into IV and TEMP1.  IV is the most 
       significant (first) 8 octets, and TEMP1 is the least 
       significant (last) 32 octets.
   5.  Decrypt TEMP1 in CBC mode using the key-encryption key.  Use     
       the IV value from the previous step as the initialization 
       vector.  Call the ciphertext CEKICV.
   6.  Decompose the CEKICV into CEK and ICV. CEK is the most 
       significant (first) 24 octets, and ICV is the least significant 
       (last) 8 octets.
   7.  Compute an 8 octet key checksum value on CEK as described 
       above.  If the computed key checksum value does not match the 
       decrypted key checksum value, ICV, then error.
   8.  Check for odd parity each of the DES key octets comprising CEK.  
       If parity is incorrect, then there is an error.

Jim Schaad sent comments to the mail list regarding the CMS-11 RC2 Key 
Wrap Algorithm.  Russ briefed the following RC2 Key Wrap algorithm 
that includes Jim's comments:
1. Let LCEKPAD = LENGTH || CEK || RANDOM_PAD.
2. Compute checksum on LCEKPAD, call result ICV.
3. Let LCEKPADICV = CEK || ICV.
4. Generate 8 octets at random, call the result IV.
5. Encrypt LCEKPADICV in CBC mode using above IV. Call ciphertext 
   TEMP1. 
6. Let TEMP2 = IV || TEMP1.
7. Let TEMP3 = REVERSE(TEMP2)
8. Encrypt TEMP3 in CBC mode using IV of 0x4adda22c79e82105.

Russ briefed the following RC2 Key Wrap algorithm that includes Jim's 
comments:
1. If the wrapped key length is not a multiple of 8, then error.
2. Decrypt wrapped key in CBC mode using IV of 0x4adda22c79e82105.  
   Call the output TEMP3.
3. TEMP2 = REVERSE(TEMP3)
4. Decompose the TEMP2 into IV and TEMP1. 
5. Decrypt TEMP1 in CBC mode using IV from above.  Call the ciphertext 
   LCEKPADICV.
6. Decompose the LCEKPADICV into LCEKPAD and ICV. 
7. Validate ICV.
8. Decompose the LCEKPAD into LENGTH, CEK and PAD. 

Russ stated that he believes that Jim's proposed changes should be 
incorporated into CMS.  Nobody objected to the inclusion of Jim's 
proposals into CMS. 

Way Forward:  A new CMS draft (CMS-12) will include the harmonized 
Triple-DES and RC2 key wrap algorithms as stated above.  CMS-12 will 
be posted as soon as the repository opens for the submission of new 
IETF drafts.  CMS-12 is ready for discussion by the IESG when the 
X9.42 draft is completed.

Russ stated that Denis Pinkas submitted comments to the S/MIME WG 
mail list requesting additional text in CMS to explain how the correct
signer's public key used to perform signature verification is
obtained.  Russ stated that he would work with Denis to derive the 
exact words to be proposed for addition to CMS and then the S/MIME WG 
members would be given the opportunity to review the proposed 
changes.


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

X9.42 Draft Discussion - Eric Rescorla

Eric discussed the status of the January 1999 D-H Key Agreement Method 
I-D (a.k.a. X9.42 I-D).  One change to be made is that the actual RC2 
key length will be the same as the effective key length.  Eric stated 
that he believes that this change resolves the RC2 partition attack.  

Eric also stated that Section 2.1.2, "Generation of Keying Material", 
will be changed to state that the KeySpecificInfo algorithm field will 
include the key wrap algorithm object identifier (OID) instead of the 
symmetric algorithm OID.  The examples will be enhanced to match this 
change.

Nobody objected to Eric's proposed changes.
  

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

Small Subgroup Attacks on D-H      Robert Zuccherato

Robert is developing an informational draft that will describe 
situations that require protection from "small subgroup" attacks on 
D-H.  The draft will also provide guidance on how to provide 
protection.

When is protection required?  In general, for sender:
1) If key is ephemeral, then no protection is required.
2) If key is static, protection is required.

In general, for a recipient (assuming static key):
1) If no information on the success of the decryption is available, no 
   protection is required.
2) If information on the success of the decryption is available, 
   protection is required.

Methods of Protection: 
1) The process by which the recipient's public key is validated by the 
   originator is described in the X9.42 draft.  This strategy is 
   possibly encumbered. Certicom has applied for a patent 
   covering the use of methods to avoid small subgroup attacks.
2) Public key validation by the Certification Authority (CA) is only 
   realistic for static public keys.
3) Choose p-1=2*q*r where r is product of "large" primes.  Must still 
   check whether public key is +/- 1.
4) Compatible Cofactor Exponentiation is described in IEEE P1363. Also 
   possibly encumbered.

Russ stated that the purpose of this document is to inform people of 
when they need to worry about small subgroup attacks.  Certicom has 
notified the S/MIME WG that they have a pending patent regarding small
subgroup attack protection.  If implementers need to be concerned with 
small subgroup attack protection, then they may wish to watch for 
this patent.
  
Eric Rescorla asked about the status of Certicom's offer for a 
royalty-free license that would allow S/MIME vendors to use the 
technology covered by their pending patent.  Russ stated that Certicom 
had not yet offered any royalty-free licenses because they do not 
believe that their pending patent covers any mandatory S/MIME 
requirements.  Russ also stated that this issue is still being worked.


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

MSG Draft Discussion - Blake Ramsdell

Blake stated that the 26 February 1999 S/MIME v3 Message Specification 
(MSG-07) I-D addresses the comments submitted to the mail list.  Blake 
stated that the MSG I-D has been submitted for IETF last call. Blake 
asked if anybody knew of any unresolved issued regarding MSG. 

Paul Hoffman proposed that the following statement should be added to 
Sec 2.2:  "Note that S/MIME v2 clients are only capable of verifying 
digital signatures using the rsaEncryption algorithm." Paul also 
proposed that the following statement should be added to Sec 2.3:  
"Note that S/MIME v2 clients are only capable of decrypting content 
encryption keys using the rsaEncryption algorithm."  Nobody objected 
to these changes.


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

CERT Draft Discussion - Blake Ramsdell

Blake stated that the 26 February 1999 S/MIME v3 Certificate Handling 
(CERT-07) I-D addresses the comments submitted to the mail list.  
Blake stated that the CERT I-D has been submitted for IETF last call. 

Blake asked if anybody knew of any unresolved issued regarding CERT.  
Denis Pinkas stated that he believed that CERT should be changed to 
state that a receiving agent "MUST support revocation" rather than 
"MUST support CRLs".  He said that his recommended wording would allow 
receiving agents to use other methods of revocation checking such as 
OCSP.  Eric Rescorla made the point that the CMS heading includes 
fields to carry CRLs, so the receiving agent must use them.  After 
several other attendees stated their opinions regarding the use of 
CRLs, Russ asked that the debate be put on hold until the end of the 
meeting so that the rest of the topics could be covered.

Denis has a second comment that he believed that the possible absence 
of the subject DN in a leaf certificate could present a problem. A 
vast majority of the meeting attendees decided that the PKIX X.509
Certificate and CRL Profile (RFC2459) (referred to by the CERT I-D)
specifies how key validation is performed using certificates that
may omit the subject DN and that CMS should not replicate that 
information.  

Paul Hoffman pointed out that section 3 in CERT-07 needed
to be modified to delete the "3.1" sub-section title. 


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

ESS Draft Discussion - Paul Hoffman

Paul stated that the 26 February 1999 Enhanced Security Services for 
SMIME (ESS-11) I-D addresses the comments submitted to the mail list.  
It has been submitted for IETF last call.  

Paul said that he will incorporate Francois Rousseau's comments sent 
to the mail list regarding the use of the signingCertificate 
attribute.


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

CERTDIST Draft Discussion - Jim Schaad

Jim stated that the 25 February 1999 Certificate Distribution 
(CERTDIST-03) I-D has not been significantly changed since the 
December 98 S/MIME WG meeting.  He said that he still needs to 
include example data in the document.  The next draft will be
submitted for S/MIME WG last call after the example data has been
added.


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

DOMSEC Draft Discussion - Bill Ottaway

Bill stated that the 17 November 1999 Domain Security Services using 
S/MIME (DOMSEC-01) I-D has been submitted to the mail list.  He stated  
that there has been no changes to the domsec draft since the December
98 S/MIME WG meeting. He is currently working on an implementation of 
domsec.  He intends to have a new draft, based on comments received
and experience gained, before the current draft expires in May 99.


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

Security Policies and Labels    Russ Housley

Russ stated that Weston Nicolls is developing an Internet draft that 
will document the security policies of Whirlpool, Caterpillar and 
Amoco.  The draft will also document how the ESSSecurityLabel can be 
used to implement those corporations' security policies.  Russ stated 
that the S/MIME WG Charter will be expanded to cover this work.  
Nobody objected.


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

S/MIME v3 Examples     Paul Hoffman

Paul stated that the 25 February 1999 Examples of CMS Message Bodies 
(EXAMPLES-00) I-D has been submitted to the mail list.  Paul stated 
that the document will include example keys, certificates and CRLs.  
The next draft will include CRLs.  The document will include some 
incorrect examples that flag common implementation errors. Paul is 
only going to coordinate putting this document together. He needs 
example data for the document and he needs people to volunteer to test 
the sample data.  Volunteers will be given credit in the document.  
Individuals would like to volunteer to do examples should contact Paul 
at [e-mail].


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

Wrap Up - Russ Housley

Russ stated that the CMS, ESS, MSG, CERT and X9.42 documents are in 
IETF Last Call.  He hopes to have these documents reviewed by the IESG 
as soon as possible.

John Pawling asked if there was a strategy for enhancing the S/MIME v3 
documents after they are approved by the IESG.  Russ stated that minor 
changes could be made in the documents when they progress from 
Proposed Standard to Draft Standard.  For example, the proposed change
to the CMS RecipientInfo syntax could be made when CMS progresses from
Proposed Standard to Draft Standard, if consensus is reached on the
handling of password-based key management.

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

Open Issues                     

The debate resumed regarding Denis Pinkas' proposal to change CERT so 
that it states that a receiving agent "MUST support revocation" rather 
than "MUST support CRLs".  After much exciting debate, the majority of 
the group reached consensus that CERT sections 2.1 and 4.1 must be 
changed to state the following:  "All agents MUST be capable of 
performing revocation checks using CRLs as specified in RFC2459.  All 
agents MUST perform revocation status checking in accordance with 
RFC2459."


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

ACTION ITEMS (These changes will be included in the S/MIME v3
documents after they have been discussed on the S/MIME WG mail
list):

1. Enhance CMS I-D to include Jim's comments regarding the RC2 key 
   wrapping and unwrapping algorithms (Russ Housley).
2. Enhance X9.42 I-D to include changes regarding RC2 key length and 
   key wrap algorithm OIDs (Eric Rescorla).
3. Develop I-D regarding small subgroup attacks on D-H (Robert 
   Zuccherato).
4. Enhance MSG I-D to include Paul's comments regarding S/MIME v2 
   agents to MSG draft (Blake Ramsdell).
5. Enhance CERT I-D sections 2.1 and 4.1 as described above (Blake 
   Ramsdell).
6. Enhance ESS I-D to include Francois Rousseau's comments regarding 
   signingCertificate attribute (Paul Hoffman).
7. Develop I-D regarding security policies and labels (Weston 
   Nicolls).
8. Incorporate sample data into Example I-D (Paul Hoffman).

=========================================================
John Pawling,  Director - Systems Engineering
J.G. Van Dyke & Associates, Inc., a Wang Global Company
[e-mail]
=========================================================




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA10792 for ietf-smime-bks; Sat, 17 Apr 1999 21:07:46 -0700 (PDT)
Received: from nty.itri.org.tw (extmx.itri.org.tw [140.96.158.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id VAA10749 for <[e-mail]>; Sat, 17 Apr 1999 21:06:56 -0700 (PDT)
From: [e-mail]
Received: by nty.itri.org.tw; (5.65v4.0/1.3/10May95) id AA24790; Sun, 18 Apr 1999 12:08:10 +0800
Received: from oax2.ccl.itri.org.tw by mail.itri.org.tw; (5.65v4.0/1.1.8.2/10Dec96-0317PM) id AA20462; Sun, 18 Apr 1999 12:07:20 +0800
Received: from autumn.ccl.itri.org.tw (autumn.ccl.itri.org.tw [140.96.83.22]) by oax2.CCL.ITRI.Org.tw (8.8.5/8.8.5) with ESMTP id MAA10045 for <[e-mail]>; Sun, 18 Apr 1999 12:07:54 +0800 (CST)
Received: from gauss (pc083070.ccl.itri.org.tw [140.96.83.70]) by autumn.ccl.itri.org.tw with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id 25VT4JP8; Sun, 18 Apr 1999 12:06:36 +0800
Message-Id: <002201be8950$b81bc810$[e-mail]>
To: "ietf(about smime)" <[e-mail]>
Subject:  What is the ToBeSignedData for signedData(pkcs#7) in SMIME system of Netscape Communicator 4.04?
Date: Sun, 18 Apr 1999 12:04:10 +0800
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01BE8993.9197E000"
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0004_01BE8993.9197E000
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: quoted-printable

Hi,
Recently, we implement SMIME system.
We use Netscape Communicator 4.04 to test our implemention.
Then we encounter the following problem.
We decrypt the SignedData(We get from smime mail of Netscape
Communicator 4.04).
We find the hash value is different from the hash value of the field
unauthenticatedAttributes(contained in SingnerInfo).
We are sure that our decrypted value is correct since it satisfy the
formate of PKCS#1.
We try hash every paragraph in SMIME mail.
One of our hash values is same as hash value in the field
unauthenticatedAttributes.
But no one is same as our decrypted value.

Our environment: Netscape Communicator 4.04, Trial Class 1 VeriSign
Digital ID.

Thanks for your help.



------=_NextPart_000_0004_01BE8993.9197E000
Content-Type: text/html;
	charset="big5"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Dbig5 http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2>Recently, we implement =
SMIME=20
system.</FONT></DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2>We use Netscape =
Communicator 4.04 to=20
test our implemention.</FONT></DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2>Then we encounter the =
following=20
problem.<BR>We decrypt the SignedData(We get from smime mail of=20
Netscape<BR>Communicator 4.04).<BR>We find the hash value is different =
from the=20
hash value of the field<BR>unauthenticatedAttributes(contained in=20
SingnerInfo).<BR>We are sure that our decrypted value is correct since =
it=20
satisfy the<BR>formate of PKCS#1.<BR>We try hash every paragraph in =
SMIME=20
mail.<BR>One of our hash values is same as hash value in the=20
field<BR>unauthenticatedAttributes.<BR>But no one is same as our =
decrypted=20
value.</FONT></DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2>Our environment: =
Netscape=20
Communicator 4.04, Trial Class 1 VeriSign<BR>Digital ID.</FONT></DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2>Thanks for your =
help.</FONT></DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 face=3DArial =
size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0004_01BE8993.9197E000--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA12623 for ietf-smime-bks; Tue, 13 Apr 1999 07:56:48 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA12616 for <[e-mail]>; Tue, 13 Apr 1999 07:56:45 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id QAA16226; Tue, 13 Apr 1999 16:56:19 +0200
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id QAA29960; Tue, 13 Apr 1999 16:56:18 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Tue, 13 Apr 1999 16:56:40 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: John Pawling <[e-mail]>
CC: S-MIME / IETF <[e-mail]>
Subject: Re: S/MIME Minutes - CMS section
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John,

If you just take the first and last sentence of your (long) proposal, I think
this is enough. This makes:

"Russ stated that Denis Pinkas submitted comments to the S/MIME WG mail list
requesting additional text in CMS to explain how the correct signer's public key
used to perform signature verification is obtained. Russ stated that he would
work with Denis to derive the exact words to be proposed for addition to CMS and
then the S/MIME WG members would be given
the opportunity to review the proposed changes."

Regards,

Denis


> All,
>
> After reviewing the tape recording of the 3/17/99 S/MIME WG meeting, I agree
> with Denis that the minutes could have been more accurate regarding the
> discussion of his comments.  I do not believe that the minutes include any
> false or misleading statements.  I disagree with Denis' proposed
> modification to the minutes because it does not accurately capture the
> events of the meeting.
>
> Based on the tape recordings of the meeting, this is what could have been
> written in the minutes:  "Russ stated that Denis Pinkas submitted comments
> to the S/MIME WG mail list requesting additional text in CMS to explain how
> the correct signer's public key used to perform signature verification is
> obtained.  Russ stated that there was no response to Denis' message on the
> list.  Russ stated that he had discussions with Denis off the list.  Russ
> stated that he was still working with Denis to derive the exact words to be
> proposed for addition to CMS.  Russ stated that Denis is especially
> concerned with the case in which multiple certificates contain the same
> public key.  John Pawling stated that the PKIX X.509 Certificate and CRL
> Profile (RFC2459) (referred to by the CERT I-D) specifies how key validation
> is performed and that CMS should not replicate that information.  There were
> many attendees who expressed their agreement with John's statement.  Russ
> stated that he would work with Denis to derive the exact words to be
> proposed for addition to CMS and then the S/MIME WG members would be given
> the opportunity to review the proposed changes."
>
> If the S/MIME WG would like me to change the official minutes to include the
> aforementioned text and then re-submit them to the IETF, then I will be
> happy to do so.  Please note that the IETF guidelines for writing meeting
> minutes (http://www.ietf.org/instructions/minutes.html) state that they
> should summarize the significant events of the meeting.  The minutes are not
> intended to capture every statement made in the meeting.  If that were the
> case, then the minutes would greatly exceed the IETF-recommended limit of
> six pages.
>
> =========================================================
> John Pawling,  Director - Systems Engineering
> J.G. Van Dyke & Associates, Inc., a Wang Global Company
> [e-mail]
> =========================================================
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA15814 for ietf-smime-bks; Mon, 12 Apr 1999 05:11:28 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA15809; Mon, 12 Apr 1999 05:11:25 -0700 (PDT)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id AAA21458; Tue, 13 Apr 1999 00:11:34 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92391909404745>; Tue, 13 Apr 1999 00:11:34 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Possible ambiguities in encoding of signatures, encrypted keys
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Tue, 13 Apr 1999 00:11:34 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

William Whyte <[e-mail]> writes:
 
>>Currently both RFC 2459 and CMS refer to RFC 2313/2437 for the encoding of RSA
>>signatures/encrypted data (RFC 2459, 7.2.1; CMS, 12.3.2.1 and 12.2.2 - what I'm
>>about to describe applies to other algorithms as well, but I'll stick with RSA
>>to keep it simple).  These RFC's make the assumption that the encoded value
>>will be of the same length as the modulus, zero-padding the value if required
>>(RFC 2437, 7.2.1 and 8.1.1), however when this padding is used the encoded
>>value doesn't follow the DER any more.
 
>I'm not sure this is right. The signature is an octet string or a bit string,
>not an integer, and it's perfectly legal to have an OCTET STRING or BIT STRING
>with leading null bytes.
 
Ah, of course!  This only leaves the signatures which have internal structure
(eg DSA, a SEQUENCE containing two INTEGER's), and they have their own rules
which don't clash with RFC 2459/CMS.
 
(Didn't PKIX at one point include a requirement for DH values, encoded as bit
 strings, to be shifted up so the MSB was the first nonzero bit in the string,
 thankfully this vanished soon after it appeared because it would've been a
 right pain to implement)
 
Is anyone aware of any implementations which break if the signature/encrypted
data value isn't padded out as required?  You'd probably have to go out of your
way to write code which does this, I'm wondering whether any code does actually
complain if the data isn't exactly the right size.  The reason I'm asking is
that I've always encoded things in the minimum number of bytes (as if it was a
DER INTEGER) rather than padding with zeroes which so far hasn't caused any
problems.
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA12118 for ietf-smime-bks; Mon, 12 Apr 1999 02:22:07 -0700 (PDT)
Received: from puma.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA12113; Mon, 12 Apr 1999 02:22:00 -0700 (PDT)
Received: by puma.baltimore.ie; id KAA21213; Mon, 12 Apr 1999 10:44:58 +0100 (GMT/IST)
Received: from ocelot.baltimore.ie(10.49.0.10) by puma.baltimore.ie via smap (4.1) id xma021196; Mon, 12 Apr 99 10:44:09 +0100
Received: from knuckle (knuckle.baltimore.ie [10.49.0.103]) by ocelot.baltimore.ie (8.8.7/8.8.5) with SMTP id KAA20706; Mon, 12 Apr 1999 10:12:07 +0100
Received: by localhost with Microsoft MAPI; Mon, 12 Apr 1999 10:20:56 +0100
Message-ID: <[e-mail]>
From: William Whyte <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Possible ambiguities in encoding of signatures, encrypted keys
Date: Mon, 12 Apr 1999 10:20:54 +0100
Organization: Baltimore Technologies
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
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-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Peter,

> Currently both RFC 2459 and CMS refer to RFC 2313/2437 for the encoding of RSA
> signatures/encrypted data (RFC 2459, 7.2.1; CMS, 12.3.2.1 and 12.2.2 - what I'm
> about to describe applies to other algorithms as well, but I'll stick with RSA
> to keep it simple).  These RFC's make the assumption that the encoded value
> will be of the same length as the modulus, zero-padding the value if required
> (RFC 2437, 7.2.1 and 8.1.1), however when this padding is used the encoded
> value doesn't follow the DER any more.

I'm not sure this is right. The signature is an octet string or a
bit string, not an integer, and it's perfectly legal to have an
OCTET STRING or BIT STRING with leading null bytes. RFC 2313 says:

8.4 Integer-to-octet-string conversion

   The integer encrypted data y shall be converted to an octet string ED
   of length k, the encrypted data. 

and it's the octet string that's encoded.

Cheers,

William


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA09910 for ietf-smime-bks; Sun, 11 Apr 1999 21:07:02 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA09906; Sun, 11 Apr 1999 21:06:58 -0700 (PDT)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id QAA04716; Mon, 12 Apr 1999 16:07:02 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92389002120806>; Mon, 12 Apr 1999 16:07:01 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Possible ambiguities in encoding of signatures, encrypted keys
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Mon, 12 Apr 1999 16:07:01 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Currently both RFC 2459 and CMS refer to RFC 2313/2437 for the encoding of RSA
signatures/encrypted data (RFC 2459, 7.2.1; CMS, 12.3.2.1 and 12.2.2 - what I'm
about to describe applies to other algorithms as well, but I'll stick with RSA
to keep it simple).  These RFC's make the assumption that the encoded value
will be of the same length as the modulus, zero-padding the value if required
(RFC 2437, 7.2.1 and 8.1.1), however when this padding is used the encoded
value doesn't follow the DER any more.  Although neither RFC 2459 or CMS
require this, the former does imply it when it says (Section 4) "the
certificate is encoded with the ASN.1 distinguished encoding rules (DER)".
Because the signature will be zero-padded a small portion of the time as per
RFC 2313/2437, it's not a DER-encoded value.  In addition I would suspect that
most implementations don't perform the zero-padding (although it's hard to
check because it occurs only about once every 256 times), so they wouldn't
comply with RFC 2313/2437.
 
The zero-padding requirement isn't something which is right or wrong one way or
the other, not padding means you get DER-compliant encodings, but padding is
necessary to allow one-pass encoding of CMS data (unless you use the indefinite
encoding all the way down) since the signature at the end of an arbitrary
amount of data could suddenly shrink by one (or more) bytes, requiring
everything to be re-encoded from the start.
 
To clear up this problem, I'd recommend the following:
 
Change the text in RFC 2459, section 4, to read:
 
  "the tbsCertificate is encoded with the ASN.1 distinguished encoding rules
   (DER)"
 
and add the following text wherever a reference to RFC 2313/2437 is made (I've
listed the section numbers above):
 
  Although RFC 2313/2437 requires that the encoded values be zero-padded to
  match the size of the modulus, this padding doesn't comply with the ASN.1
  distinguished encoding rules (DER) which allow at most one leading zero byte,
  and only if the MSB of the value is set.  Some implementations may choose to
  pad the value as per the RFC's, others may choose to follow the DER.  Both of
  these encoding forms are acceptable, and implementations should be able to
  process both zero-padded and non-padded values.
 
If necessary I guess RFC 2459 could be a bit more strict (always require DER),
but CMS should allow both forms since, as I've outlined above, requiring DER
would make one-pass encoding impossible.
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA29098 for ietf-smime-bks; Fri, 9 Apr 1999 08:52:39 -0700 (PDT)
Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA29094 for <[e-mail]>; Fri, 9 Apr 1999 08:52:38 -0700 (PDT)
Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id LAA20813 for <[e-mail]>; Fri, 9 Apr 1999 11:58:48 -0400 (EDT)
Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id LAA21187; Fri, 9 Apr 1999 11:55:39 -0400
Date: Fri, 9 Apr 1999 11:55:39 -0400
Message-Id: <[e-mail]>
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: S-MIME / IETF <[e-mail]>
From: [e-mail] (John Pawling)
Subject: Re: S/MIME Minutes - CMS section
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

After reviewing the tape recording of the 3/17/99 S/MIME WG meeting, I agree
with Denis that the minutes could have been more accurate regarding the
discussion of his comments.  I do not believe that the minutes include any
false or misleading statements.  I disagree with Denis' proposed
modification to the minutes because it does not accurately capture the
events of the meeting.  

Based on the tape recordings of the meeting, this is what could have been
written in the minutes:  "Russ stated that Denis Pinkas submitted comments
to the S/MIME WG mail list requesting additional text in CMS to explain how
the correct signer's public key used to perform signature verification is
obtained.  Russ stated that there was no response to Denis' message on the
list.  Russ stated that he had discussions with Denis off the list.  Russ
stated that he was still working with Denis to derive the exact words to be
proposed for addition to CMS.  Russ stated that Denis is especially
concerned with the case in which multiple certificates contain the same
public key.  John Pawling stated that the PKIX X.509 Certificate and CRL
Profile (RFC2459) (referred to by the CERT I-D) specifies how key validation
is performed and that CMS should not replicate that information.  There were
many attendees who expressed their agreement with John's statement.  Russ
stated that he would work with Denis to derive the exact words to be
proposed for addition to CMS and then the S/MIME WG members would be given
the opportunity to review the proposed changes."  

If the S/MIME WG would like me to change the official minutes to include the
aforementioned text and then re-submit them to the IETF, then I will be
happy to do so.  Please note that the IETF guidelines for writing meeting
minutes (http://www.ietf.org/instructions/minutes.html) state that they
should summarize the significant events of the meeting.  The minutes are not
intended to capture every statement made in the meeting.  If that were the
case, then the minutes would greatly exceed the IETF-recommended limit of
six pages.

=========================================================
John Pawling,  Director - Systems Engineering
J.G. Van Dyke & Associates, Inc., a Wang Global Company
[e-mail]
=========================================================
  



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA27877 for ietf-smime-bks; Fri, 9 Apr 1999 06:58:18 -0700 (PDT)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA27873 for <[e-mail]>; Fri, 9 Apr 1999 06:58:17 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id GAA13037; Fri, 9 Apr 1999 06:57:15 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 09 Apr 1999 09:56:06 -0400
To: Dr Stephen Henson <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: CMS-12 Error???
Cc: "[e-mail]" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve:

The X942-07 draft specifies how to generate RC2 KEKs of any length.  It
uses 40 bits and 128 bits ans the explicit examples.  CMS-12 syas that RC2
KEKs must be 128 bits.

I still do not see a problem.

Russ


At 06:13 PM 4/7/99 +0100, Dr Stephen Henson wrote:
>Russ Housley wrote:
>> 
>> Steve:
>> 
>> CMS-12, Section 12.3.1 says:
>>    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].
>> 
>> X942-07, Section 2.1.3 says:
>>    ... For RC2-128, which
>>    requires 128 bits of keying material, the algorithm is run once, with
>>    a counter value of 1, and the left-most 128 bits are directly con-
>>    verted to an RC2 key. Similarly, for RC2-40, which requires 40 bits
>>    of keying material, the algorithm is run once, with a counter value
>>    of 1, and the leftmost 40 bits are used as the key.
>> 
>> X942-07, Section 2.1.4 says:
>>    RC2 effective key lengths are equal to RC2 real key lengths.
>> 
>> I think that we are consistent.  CMS-12 is simply mandating that RC2 KEKs
>> be 128-bit keys, and X942-07 says that the effective key length cannot be
>> used to weaken the key.
>> 
>> Okay?
>> 
>
>Hmmm I'm not so sure of this myself. I'm may have messed up the
>interpretation here, in which case apologies in advance, but...
>
>X942-07 2.1.4 appears to be saying that the effective key length and
>real key length for RC2 are the same when used as a KEK algorithm. For
>example 40 bit RC2 would have an effective key length of 40 bits and
>have a real key length of 40 bits.
>
>CMS 12.3.1 says 128 bits of keying material must be generated for RC2
>when used as a KEK algorithm.
>
>Combine the two and I'd interpret this to mean that the effective key
>length of RC2 (and thus the actual key length) must be 128 bits when
>used as a KEK algorithm. That is only 128 bit RC2 can be used as a KEK
>algorithm.
>
>That in itself isn't a problem but CMS 12.3.2 says:
>
>12.3.3.2  RC2 Key Wrap
>
>   RC2 key encryption has the algorithm identifier:
>
>      id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
>          us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 }
>
>   The AlgorithmIdentifier parameter field must be RC2wrapParameter:
>
>      RC2wrapParameter ::= RC2ParameterVersion
>
>      RC2ParameterVersion ::= INTEGER
>
>   The RC2 effective-key-bits (key size) greater than 32 and less than
>   256 is encoded in the RC2ParameterVersion.  For the effective-key-
>   bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120,
>   and 58 respectively.  These values are not simply the RC2 key length.
>   Note that the value 160 must be encoded as two octets (00 A0),
>   because the one octet (A0) encoding represents a negative number.
>
>This seems to suggest that RC2 can be used as a KEK algorithm with
>effective key lengths other than 128 bits.
>
>Steve.
>-- 
>Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
>Personal Email: [e-mail] 
>Senior crypto engineer, Celo Communications: http://www.celocom.com/
>Core developer of the   OpenSSL project: http://www.openssl.org/
>Business Email: [e-mail] PGP key: via homepage.
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA27695 for ietf-smime-bks; Fri, 9 Apr 1999 06:27:44 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA27691 for <[e-mail]>; Fri, 9 Apr 1999 06:27:41 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id PAA25678; Fri, 9 Apr 1999 15:27:32 +0200
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id PAA26258; Fri, 9 Apr 1999 15:27:33 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Fri, 09 Apr 1999 15:27:41 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: S-MIME / IETF <[e-mail]>, John Pawling <[e-mail]>
Subject: READ First ***! S/MIME minutes -CMS
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I just realized that I took the wrong file so half of my comments
are inappropriate.

The minutes are not correct, but the new CMS 12 document does
incorporate some changes.

So, please, Russ accept my apologies.

Here is the text.

5.6  Message Signature Verification Process

   The input to the signature verification process includes the
result
   of the message digest calculation process and the signer's
public
   key.  The recipient may obtain the correct public key for the
signer
   by any means, but the preferred method is from a certificate
obtained
   from the SignedData certificates field.  The selection and
validation
   of the signer's public key may be based on certification path
   validation (see [PROFILE]) as well as other external context,
but is
   beyond the scope of this document.  The details of the
signature
   verification depend on the signature algorithm employed.

Regards,

Denis







Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA27587 for ietf-smime-bks; Fri, 9 Apr 1999 06:18:54 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA27581 for <[e-mail]>; Fri, 9 Apr 1999 06:18:39 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id PAA11614; Fri, 9 Apr 1999 15:18:47 +0200
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id PAA28334; Fri, 9 Apr 1999 15:18:31 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Fri, 09 Apr 1999 15:18:39 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: John Pawling <[e-mail]>, Russ Housley <[e-mail]>
CC: S-MIME / IETF <[e-mail]>
Subject: S/MIME Minutes - CMS section
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John,

I only got the time to look at the minutes yesterday and observed
a difference between what happened during the meeting and what is
written.

In the section about CMS, it is said:

" Russ asked if there were any other unresolved issued regarding
CMS. Denis Pinkas stated that he believes that CMS should specify
how key validation is performed.  He is especially concerned with
the case in which multiple Certification Authority (CA)
certificates contain the same public key.  A vast majority of the
meeting attendees decided that the PKIX X.509 Certificate and CRL
Profile (RFC2459) (referred to by the CERT I-D) specifies how key
validation is performed and that CMS should not replicate that
information."

On that point, during the session Russ said that he was willing
to incorporate additional text in the security consideration
section that I had provided to him to address this concern. I did
not commented on this and no one else. There was no strawpol
either on this issue.

A more correct formulation should be:

"Russ said Denis Pinkas had been asking for some addditional text
to explain how the right public key to perform the verification
of the signature was obtained in section 5.6. Denis Pinkas had
provided to Russ some text for additional materail to the
security consideration section and a pointer to it in the section
5.6. Russ said he would incoporate the new text in the next
draft. "

Note that this has nothing to do with how key validation is
performed, which is indeed explained in the PKIX X.509
Certificate and CRL Profile (RFC2459) (referred to by the CERT
I-D), so it does not duplicate any text.

After the meeting Russ sent me privately an E-mail to say that he
finally founded the text too big and instead proposed me to
change some text of the section 5.6. I replied that this was
acceptable (although I would have prefered the first way).

Now when looking at the document (cms-12) I find the text
unchanged.

I would like that we correct the minutes, if possible, but what I
care much more is the content of CMS. I am still requesting
changes to CMS section 5.6. one way or the other to address this
issue. Russ ?

Regards,

Denis





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA00239 for ietf-smime-bks; Wed, 7 Apr 1999 10:17:49 -0700 (PDT)
Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA00234 for <[e-mail]>; Wed, 7 Apr 1999 10:17:48 -0700 (PDT)
Received: from [193.237.150.98] (helo=celocom.com) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 10Uvy0-0009yK-0B for [e-mail]; Wed, 7 Apr 1999 17:18:20 +0000
Message-ID: <[e-mail]>
Date: Wed, 07 Apr 1999 18:13:47 +0100
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.08 [en] (Win95; U)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: CMS-12 Error???
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-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ Housley wrote:
> 
> Steve:
> 
> CMS-12, Section 12.3.1 says:
>    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].
> 
> X942-07, Section 2.1.3 says:
>    ... For RC2-128, which
>    requires 128 bits of keying material, the algorithm is run once, with
>    a counter value of 1, and the left-most 128 bits are directly con-
>    verted to an RC2 key. Similarly, for RC2-40, which requires 40 bits
>    of keying material, the algorithm is run once, with a counter value
>    of 1, and the leftmost 40 bits are used as the key.
> 
> X942-07, Section 2.1.4 says:
>    RC2 effective key lengths are equal to RC2 real key lengths.
> 
> I think that we are consistent.  CMS-12 is simply mandating that RC2 KEKs
> be 128-bit keys, and X942-07 says that the effective key length cannot be
> used to weaken the key.
> 
> Okay?
> 

Hmmm I'm not so sure of this myself. I'm may have messed up the
interpretation here, in which case apologies in advance, but...

X942-07 2.1.4 appears to be saying that the effective key length and
real key length for RC2 are the same when used as a KEK algorithm. For
example 40 bit RC2 would have an effective key length of 40 bits and
have a real key length of 40 bits.

CMS 12.3.1 says 128 bits of keying material must be generated for RC2
when used as a KEK algorithm.

Combine the two and I'd interpret this to mean that the effective key
length of RC2 (and thus the actual key length) must be 128 bits when
used as a KEK algorithm. That is only 128 bit RC2 can be used as a KEK
algorithm.

That in itself isn't a problem but CMS 12.3.2 says:

12.3.3.2  RC2 Key Wrap

   RC2 key encryption has the algorithm identifier:

      id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 }

   The AlgorithmIdentifier parameter field must be RC2wrapParameter:

      RC2wrapParameter ::= RC2ParameterVersion

      RC2ParameterVersion ::= INTEGER

   The RC2 effective-key-bits (key size) greater than 32 and less than
   256 is encoded in the RC2ParameterVersion.  For the effective-key-
   bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120,
   and 58 respectively.  These values are not simply the RC2 key length.
   Note that the value 160 must be encoded as two octets (00 A0),
   because the one octet (A0) encoding represents a negative number.

This seems to suggest that RC2 can be used as a KEK algorithm with
effective key lengths other than 128 bits.

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA28405 for ietf-smime-bks; Wed, 7 Apr 1999 06:45:34 -0700 (PDT)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA28401 for <[e-mail]>; Wed, 7 Apr 1999 06:45:33 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id GAA02466; Wed, 7 Apr 1999 06:45:19 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 07 Apr 1999 09:44:56 -0400
To: Dr Stephen Henson <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: CMS-12 Error???
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve:

CMS-12, Section 12.3.1 says:
   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].

X942-07, Section 2.1.3 says:
   ... For RC2-128, which
   requires 128 bits of keying material, the algorithm is run once, with
   a counter value of 1, and the left-most 128 bits are directly con-
   verted to an RC2 key. Similarly, for RC2-40, which requires 40 bits
   of keying material, the algorithm is run once, with a counter value
   of 1, and the leftmost 40 bits are used as the key.

X942-07, Section 2.1.4 says:
   RC2 effective key lengths are equal to RC2 real key lengths.

I think that we are consistent.  CMS-12 is simply mandating that RC2 KEKs
be 128-bit keys, and X942-07 says that the effective key length cannot be
used to weaken the key.

Okay?

Russ

>Return-Path: <[e-mail]>
>Date: Wed, 31 Mar 1999 21:24:42 +0000
>From: Dr Stephen Henson <[e-mail]>
>Organization: Dr S N Henson
>To: "[e-mail]" <[e-mail]>
>Subject: RC2 keylength in CMS.
>
>In CMS there are still a couple of references to the RC2 key length
>being always 128 bits. Specifically 12.3.1 and 12.6. 
>
>Whereas X9.42 refelects the change and that RC2 effective and real key
>lengths are equal.
>
>Steve.
>-- 
>Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
>Personal Email: [e-mail] 
>Senior crypto engineer, Celo Communications: http://www.celocom.com/
>Core developer of the   OpenSSL project: http://www.openssl.org/
>Business Email: [e-mail] PGP key: via homepage.
>
>




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA08383 for ietf-smime-bks; Tue, 6 Apr 1999 21:05:01 -0700 (PDT)
Received: from ixpres.com (AM3-10-53-206.ixpres.com [209.75.53.206]) by mail.proper.com (8.8.8/8.8.5) with SMTP id UAA07726; Tue, 6 Apr 1999 20:53:14 -0700 (PDT)
Date: Tue, 6 Apr 1999 20:53:14 -0700 (PDT)
From: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
To: [e-mail]
Subject: Organize Web Info...
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

This message is sent in compliance of the new Email bill: SECTION 301.
Sender: INFOtrepreneur, 11012 Avenida De Los Lobos, San Diego, 
California, CA 92127 - Fax: [phone] Email: [e-mail]
Per Section 301, Paragraph (a)(2)(C) of S.1618, further transmissions to you 
by the sender of this email may be stopped at no cost to you by ending a reply 
to this email address with the word "remove" in the subject line.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

NO MORE!  BACKTRACKING OF LOST AND CONFUSING 
WEB BOOKMARKS AND TEXT DATA FILES...

Based upon your Internet interests, I thought that you would be 
interesed in Web Info Catcher which allows you to capture and store 
text data from various sources, index, categorize and edit it instantly on 
screen while online.

Access all your reference and source material instantly at a click of a button,
while you are working, browsing, searching or offline. 

It's the fastest, up-to-date, and most efficient means to "RECALL" your data.
 
  * No need... to bookmark a multitude of web sites 
  * No need... to search for misplaced or lost text files 
  * No need... to print out endless reports 
  * No need... for a web browser to reference data

- Perfect for academics, researchers, business, info junkies, etc. 
- Create your own projects, reports, topics, favorites, research, etc. 
- Open numerous projects and setup your own index references 
- Attach and Capture text information from various sources 
- Edit your projects 
- Effectively organize your information 
- Categorize your information 
- Add custom indexes 
- Automatic alpha indexing 
- Searchable index 
- Scrollable index
- View information on screen while working 
- A Stand alone program 
- Add and delete information 
- Print out data in your own time

WHY BOOKMARK OR SAVE YOUR TEXT FILES?

DON'T DELAY!  Visit INFOtrepreneur today and discover a whole new way to 
capture and store your information sources, we will be happy to assist you.

DOWNLOAD your software demo: ftp://ftp.infotrepreneur.com/pub/wicdemo.exe

OR for more info: http://www.infotrepreneur.com/webcth.htm 

Sincerely
Gail van der Merwe




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA19273 for ietf-smime-bks; Tue, 6 Apr 1999 09:44:57 -0700 (PDT)
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA19269; Tue, 6 Apr 1999 09:44:50 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.32 (Beta)
Date: Tue, 06 Apr 1999 09:44:59 -0700
To: "Teiwes, Stephan (Ascom Systec AG)" <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-idea-00.txt
Cc: "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail] om.ch>
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-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 01:43 PM 4/6/99 +0200, Teiwes, Stephan (Ascom Systec AG) wrote:
>        We have written our draft with the intention to support developers
>with important implementation and application information. Since not every
>SW developer in IT-security is an expert in S/MIME, we believe it is
>required to give more than just the OID and licensing information. However,
>we are thankful for every helpful comment to make the draft clearer for a
>better understanding.

I strongly disagree with your intention on the draft, then. If you repeat 
any information from -msg and you do it in a way that is not exact 
quotation, you do a disservice to the S/MIME community by giving your own 
interpretation of the standard. And, if you do use extensive quoting, 
you're wasting paper. Give as little information as needed and refer to the 
standard for everything else.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA15833 for ietf-smime-bks; Tue, 6 Apr 1999 04:49:02 -0700 (PDT)
Received: from ascomax.hasler.ascom.ch (ascomax.hasler.ascom.ch [139.79.129.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA15828; Tue, 6 Apr 1999 04:48:57 -0700 (PDT)
Received: from rmus2 (rmus2.systec.ascom.ch [139.79.41.3]) by ascomax.hasler.ascom.ch (8.9.1/8.9.1) with SMTP id NAA07396; Tue, 6 Apr 1999 13:49:29 +0200 (MET DST)
Received: from ntserver.systec.ascom.ch by rmus2 (SMI-8.6/SMI-4.1) id NAA20136; Tue, 6 Apr 1999 13:38:13 +0200
Received: by NTSERVER.systec.ascom.ch with Internet Mail Service (5.0.1460.8) id <2AZZQYPG>; Tue, 6 Apr 1999 13:43:07 +0200
Message-ID: <[e-mail]>
From: "Teiwes, Stephan (Ascom Systec AG)" <[e-mail]>
To: "'Paul Hoffman / IMC'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-idea-00.txt
Date: Tue, 6 Apr 1999 13:43:05 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BE8022.A2E1A7A0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
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_000_01BE8022.A2E1A7A0
Content-Type: text/plain

	Paul Hoffman wrote:

> I have a few objections to this draft that I would like to see cleared up 
> before any further discussion happens on the draft.
> 
> The draft does not have the mandatory notice about whether or not it 
> complies with RFC 2026. Without this notice, the authors could claim that 
> they do not release copyright on the draft to the IETF, and therefore we 
> may not be able to use the discussions of the draft in the future.
> 
> The draft seems more like a marketing effort than a technical 
> specification. All the talk about integration with S/MIME, the history of 
> IDEA, and so on is pretty useless. A simple document saying "here's the 
> OID, here are the parameters, here's our patent statement" would suffice. 
> (I find it particularly galling that the sentence "S/MIME is constructed
> as 
> an open system." is used near the beginning of the draft as a way to make 
> nice before proposing an algorithm that is heavily protected by patents.)
> 
> The draft restates some of the MUSTs and SHOULDs from the -msg draft,
> which 
> is completely inappropriate. All such restatements should be removed, 
> leaving just the changes that this draft would make to the 
> hopefully-soon-to-be-standard.
> 
> There is no Security Considerations section; I think one would be 
> appropriate, given that this is proposing an algorithm that is not widely 
> known.
> 
> The statement "Commercial licenses can be obtained by contacting 
> [e-mail]" is interesting, if true. I was told a few years ago that a 
> company that applied for an IDEA license for PGP was flatly rejected 
> without any talk of the cost (I have no verification of this). Perhaps the
> 
> authors of this draft should reword the sentence, or spell out what they 
> mean in terms similar to those used in RFC 2026 and RFC 2028.
> 
	======================================================

	We will definitely include the mandatory notice about the compliance
of our draft with
	RFC 2026. Of course, it is our intention to release copyright on the
draft to the IETF!

	Ascom Systec's policy about IDEA licensing has changed already some
years ago.
	Today, everybody can easily obtain IDEA licenses at low costs for
instance by using our online lincence order service at
http://www.ascom.ch/infosec/ . We would also like to emphasize that IDEA is
free for non-commercial use. 

	The attached reference list of IDEA users should be proof enough
that IDEA is
	not only widely known but also widely accepted !

	We have written our draft with the intention to support developers
with important implementation and application information. Since not every
SW developer in IT-security is an expert in S/MIME, we believe it is
required to give more than just the OID and licensing information. However,
we are thankful for every helpful comment to make the draft clearer for a
better understanding.

	 <<referencesIDEA.doc>> 

----------------------------------------------------------------------------
|  Dr. Stephan Teiwes
|  Ascom Systec AG, CH-5506 Maegenwil
|  Phone: +41 (0)62 / 889 59 36 
|  Fax:   +41 (0)62 / 889 59 99
|  EMail: [e-mail] 
|
|  Information Security with IDEA@corporate products
|  http://www.ascom.com/infosec
----------------------------------------------------------------------------






------ =_NextPart_000_01BE8022.A2E1A7A0
Content-Type: application/msword;
	name="referencesIDEA.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="referencesIDEA.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAKwAAAAAAAAAA
EAAALQAAAAEAAAD+////AAAAACoAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////s
pcEAWQAHBAAAABK/AAAAAAAAEAAAAAAABAAAug0AAA4AYmpiavNX81cAAAAAAAAAAAAAAAAAAAAA
AAAHBBYAHiIAAJE9AQCRPQEAugkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA
AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAEoBAAAAAAAASgEAAEoB
AAAAAAAASgEAAAAAAABKAQAAAAAAAEoBAAAAAAAASgEAABQAAAAAAAAAAAAAAF4BAAAAAAAAXgEA
AAAAAABeAQAAAAAAAF4BAAAAAAAAXgEAAAwAAABqAQAAHAAAAF4BAAAAAAAAgggAADYBAACSAQAA
AAAAAJIBAAAAAAAAkgEAAAAAAACSAQAAAAAAAJIBAAAAAAAAkgEAAAAAAACSAQAAAAAAAJIBAAAA
AAAARwgAAAIAAABJCAAAAAAAAEkIAAAAAAAASQgAAAAAAABJCAAAAAAAAEkIAAAAAAAASQgAACQA
AAC4CQAA9AEAAKwLAACUAAAAbQgAABUAAAAAAAAAAAAAAAAAAAAAAAAASgEAAAAAAACSAQAAAAAA
AAAAAAAAAAAAAAAAAAAAAACSAQAAAAAAAJIBAAAAAAAAkgEAAAAAAACSAQAAAAAAAG0IAAAAAAAA
OgYAAAAAAABKAQAAAAAAAEoBAAAAAAAAkgEAAAAAAAAAAAAAAAAAAJIBAAAAAAAAkgEAAAAAAAA6
BgAAAAAAADoGAAAAAAAAOgYAAAAAAACSAQAAqAQAAEoBAAAAAAAAkgEAAAAAAABKAQAAAAAAAJIB
AAAAAAAARwgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXgEAAAAAAABeAQAAAAAAAEoBAAAAAAAASgEA
AAAAAABKAQAAAAAAAEoBAAAAAAAAkgEAAAAAAABHCAAAAAAAADoGAACUAQAAOgYAAAAAAADOBwAA
HgAAACcIAAAYAAAASgEAAAAAAABKAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARwgAAAAAAACSAQAAAAAAAIYBAAAMAAAAkHAWpCKA
vgFeAQAAAAAAAF4BAAAAAAAAOgYAAAAAAAA/CAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUmVm
ZXJlbmNlIGxpc3Qgb2YgSURFQSB1c2VycyAobGlzdCBpcyBub3QgY29tcGxldGUpDUJhbmtzLCBJ
bnN1cmFuY2VzDVNjaHdlaXplcmlzY2hlIEJhbmtnZXNlbGxzY2hhZnQsIFNjaHdlaXoNU2Nod2Vp
emVyaXNjaGVyIEJhbmt2ZXJlaW4sIFNjaHdlaXoNQmFuayBKdWxpdXMgQmFlciwgU2Nod2Vpeg1C
YW5rIENvdXR0cyAmIENvLCBTY2h3ZWl6DUNvbW1lcnpiYW5rIChTY2h3ZWl6KSBBRywgU2Nod2Vp
eg1FdXJvcGF5IChTd2l0emVybGFuZCkgUy5BLiwgU2Nod2Vpeg1Mb21iYXJkLCBPZGllciAmIENp
ZSwgU2Nod2Vpeg1EcmVzZG5lciBCYW5rIEFHLCBEZXV0c2NobGFuZA1CYW5xdWUgQ3LpZ2VtLCBM
dXhlbmJ1cmcNQmFucXVlIEfpbulyYWxlIGR1IEx1eGVtYm91cmcsICBMdXhlbmJ1cmcNQmFucXVl
IE5hdGlvbmFsZSBCZWxnaXF1ZSwgQmVsZ2llbg1CYW5jYSBDb21tZXJjaWFsZSBJdGFsaWFuYSBT
UEEsIEl0YWxpZW4NQ29tbWVyemJhbmsgQUcsICBTcGFuaWVuDUJhbmNvIFJlYWwgUy5BLiwgU3Bh
bmllbg1DYWphIFJ1cmFsIGRlIEFsZ2VtZXNpLCBTcGFuaWVuDUNhaXhhIGRlbHMgQWR2b2NhdHMs
IFNwYW5pZW4NQmFuY28gZGUgRXNwYW5hLCBTcGFuaWVuDU5hdGlvbmFsIFdlc3RtaW5zdGVyIEJh
bmsgUExDLCBTcGFuaWVuDUNyZWRpdCBDb21tZXJjaWFsIGRlIEZyYW5jZSwgRnJhbmtyZWljaA1D
cmVkaXRhbnN0YWx0LCDWc3RlcnJlaWNoDURlbiBEYW5za2UgQmFuaywgRORuZW1hcmsNRGUgTmVk
ZXJsYW5kc2NoZSBCYW5rLCBIb2xsYW5kDU1lcml0YSBCYW5rIEx0ZC4sIEZpbm5sYW5kDUJhbmNv
IGRvIEJyYXNpbCwgQnJhc2lsaWVuDUJhbmsgb2YgU291dGggQXVzdHJhbGlhLCBBdXN0cmFsaWVu
DVJveWFsIEJhbmsgb2YgU2NvdGxhbmQsIFNjaG90dGxhbmQNTWFzdGVyY2FyZCBJbnRlcm5hdGlv
bmFsIEluYy4sIFVTQQ1EZXV0c2NoZSBCYW5rLCBTaW5nYXB1cg0NSW5kdXN0cnkNQXNjb20gQXV0
ZWxjYSwgU2Nod2Vpeg1MYW5kaXMgJiBHeXIgQUcsIFNjaHdlaXoNTWlncm9zIEdlbm9zc2Vuc2No
YWZ0cyBCdW5kLCBTY2h3ZWl6DVNhbmRveiBQaGFybWEgTHRkLiwgU2Nod2Vpeg1BdWRpIEFHLCBE
ZXV0c2NobGFuZA1CTVcgUm9sbHMgUm95Y2UgR21iSCwgRGV1dHNjaGxhbmQNSG9lY2hzdCBBRywg
RGV1dHNjaGxhbmQNVm9sa3N3YWdlbiBBRywgRGV1dHNjaGxhbmQNU2llbWVucywgRGV1dHNjaGxh
bmQNSUJEIEdtYkggLyBQb3JzY2hlIEFHLCBEZXV0c2NobGFuZA1NYW5uZXNtYW5uIE1vYmlsZnVu
ayBHbWJILCBEZXV0c2NobGFuZA1NaXRzdWJpc2hpIEVsZWN0cmljLCBKYXBhbg1Nb3Rvcm9sYSwg
VVNBDU5pc3NpbiwgSmFwYW4NQ29tcHV0ZXIsIENvbW11bmljYXRpb24NTGlnaHRuaW5nIEluc3Ry
dW1lbnRhdGlvbiwgU2Nod2Vpeg1NYXJ4IERhdGVudGVjaG5paywgRGV1dHNjaGxhbmQNTGFuZ2Ug
RWxlY3Ryb25pYywgRGV1dHNjaGxhbmQNUlZTIERhdGVudGVjaG5paywgRGV1dHNjaGxhbmQNQ3Jh
eSBDb21tdW5pY2F0aW9ucywgRORuZW1hcmsNSGlnaHdhcmUgSW5jLiwgQmVsZ2llbg1GVFAgU29m
dHdhcmUsIFVTQQ1JQk0sIFVTQQ1QR1AgSW5jLiwgVVNBDU5ldHNjYXBlIENvbW11bmljYXRpb25z
LCBVU0ENTmV0d29yayBTeXN0ZW1zIENvcnAuLCBVU0ENQXV0aG9yaXRpZXMsIEhlYWx0aCBjYXJl
DUVpZGdlbvZzc2lzY2hlcyBNaWxpdORyZGVwYXJ0ZW1lbnQsIFNjaHdlaXoNSW5zZWxzcGl0YWwg
QmVybiwgU2Nod2Vpeg1CdW5kZXNhbXQgZvxyIEp1c3RpeiwgU2Nod2Vpeg1BbXQgZvxyIExhbmR3
aXJ0c2NoYWZ0IGRlcyBLdC4gQmVybiwgU2Nod2Vpeg1Cb3RzY2hhZnQgZGVyIFJlcHVibGlrIFBv
bGVuLCBTY2h3ZWl6DURldXRzY2hlcyBLcmVic2ZvcnNjaHVuZ3N6ZW50cnVtLCBEZXV0c2NobGFu
ZA1BZXJvc3BhY2UsIFRyYW5zcG9ydGF0aW9uDUZsdWdoYWZlbiBN/G5jaGVuLCBEZXV0c2NobGFu
ZA1EZXV0c2NoZSBMdWZ0aGFuc2EgQUcsIERldXRzY2hsYW5kDUVuZXJnaWUgVmVyc29yZ3VuZyBT
Y2h3YWJlbiBBRywgRGV1dHNjaGxhbmQNRGFpbWxlciBCZW56IEFlcm9zcGFjZSwgRGV1dHNjaGxh
bmQNSW5zdGl0dXQgZvxyIE1vYmlsLSB1bmQgU2F0ZWxsaXRlbmZ1bmssIERldXRzY2hsYW5kDUJy
aXRpc2ggQWVyb3NwYWNlIEx0ZC4sIEVuZ2xhbmQNTlJTQSBEZXBhcnRtZW50IG9mIFNwYWNlLCBJ
bmRpZW4NVGVsZWNvbXMNU3dpc3MgT25saW5lLCBTY2h3ZWl6DURldXRzY2hlIFRlbGVrb20sIERl
dXRzY2hsYW5kDURldXRzY2hlIFBvc3QgQUcsIERldXRzY2hsYW5kDVRlbGVjb20gRmlubGFuZCwg
RmlubmxhbmQNVGVsZWZvbmljYSBkZSBFc3BhbmEgUy5BLiwgU3Bhbmllbg1UZWxlY29tLCBLb2x1
bWJpZW4NU2VydmljZXMJDU9yZWxsIEb8c3NsaSBTZWN1cml0eSBEb2N1bWVudHMgQUcsIFNjaHdl
aXoNTWF4IFBsYW5jayBHZXNlbGxzY2hhZnQsIERldXRzY2hsYW5kDVJldXRlcnMgQXNpYSwgSG9u
ZyBLb25nDU1jS2luc2V5ICYgQ29tcGFueSBMdGQuLCBVU0ENAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAARgQAAJMEAABb
BwAAoAcAAKEHAAC5BwAAugcAAMIHAADDBwAAMwkAADQJAABMCQAAXwoAAGAKAAB5CgAAvwoAAF4L
AAB4CwAAfwwAAIgMAAApDQAAKg0AADQNAAC6DQAA+wD1APAA8PvqAPD7APD7APX7APsA8PsAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL
NQiBT0oDAFFKAwAIT0oCAFFKAgAAC2gIAG1IBwhuSAcECE9KAwBRSgMAGAAEAAA0BAAARgQAAG8E
AACTBAAArQQAAMcEAADpBAAADQUAACsFAABJBQAAYgUAAIwFAACvBQAA1wUAAPAFAAAJBgAAKQYA
AEYGAABfBgAAhgYAAK4GAADIBgAA4gYAAAEHAAAcBwAANwcAAFsHAAB+BwAAoQcAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA
+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAA
AAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAA
AAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsA
AAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAA
AAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAA
APsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAAAAAAAAAAARAAAAEPAAAdAAQAADQEAABGBAAAbwQA
AJMEAACtBAAAxwQAAOkEAAANBQAAKwUAAEkFAABiBQAAjAUAAK8FAADXBQAA8AUAAAkGAAApBgAA
RgYAAF8GAACGBgAArgYAAMgGAADiBgAAAQcAABwHAAA3BwAAWwcAAH4HAAChBwAAuQcAALoHAADD
BwAA2gcAAPMHAAAYCAAANAgAAEkIAABrCAAAgwgAAJ4IAACzCAAA1ggAAP0IAAAYCQAAJgkAADQJ
AABMCQAAbwkAAI4JAACsCQAAygkAAOgJAAD/CQAAEQoAABoKAAAoCgAARQoAAGAKAABrCgAAbQoA
AG4KAAB4CgAAeQoAAKUKAAC/CgAA3QoAAAoLAAAwCwAAXgsAAGkLAAByCwAAdwsAAHgLAACXCwAA
ugsAAOYLAAAKDAAAPgwAAF4MAAB/DAAAiAwAAJ4MAAC8DAAA2gwAAPQMAAAXDQAAKg0AADQNAABg
DQAAhQ0AAJ0NAAC6DQAA/f34+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4AP34+Pj4+Pj4+Pj4
+Pj4+P34+Pj4+Pj4+Pj4+Pb29vb2+Pj4+Pj49vb29vj4+Pj4+Pj9+Pj4+Pj4/fj4+PgAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEBAAgCEAAIEgAJAQADAg8AAFyhBwAAuQcAALoHAADDBwAA
2gcAAPMHAAAYCAAANAgAAEkIAABrCAAAgwgAAJ4IAACzCAAA1ggAAP0IAAAYCQAAJgkAADQJAABM
CQAAbwkAAI4JAACsCQAAygkAAOgJAAD/CQAAEQoAABoKAAAoCgAARQoAAP0AAAAAAAAAAAAAAAD7
AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA
AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAAAAAAAAAAAAAADDwATpGgBAw8AByQBAAEAAAABEAAAHEUKAABgCgAAeQoAAKUKAAC/
CgAA3QoAAAoLAAAwCwAAXgsAAHgLAACXCwAAugsAAOYLAAAKDAAAPgwAAF4MAAB/DAAAiAwAAJ4M
AAC8DAAA2gwAAPQMAAAXDQAAKg0AADQNAABgDQAAhQ0AAJ0NAAC6DQAA/QAAAAAAAAAAAAAAAPkA
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA
AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA
AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA
AAAAAAAAAAAA/QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD5
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAADDwATpGgBAAEQAAAcHAAfsIIuILDGQSGwiQUisIkF
I5CJBSSQbgQlsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASABIACgABAFsADwACAAAAAAAA
ACgAAEDx/wIAKAAAAAgAUwB0AGEAbgBkAGEAcgBkAAAAAgAAAAQAbUgHBAAAAAAAAAAAAAAAAAAA
AAAAAEIAQUDy/6EAQgAAABkAQQBiAHMAYQB0AHoALQBTAHQAYQBuAGQAYQByAGQAcwBjAGgAcgBp
AGYAdABhAHIAdAAAAAAAAAAAAAAAAAAwAP5PAQDyADAAAAAEAFQARQBYAFQAAAAKAA8AD4RTAxOk
8AAMAENKFgBPSgQAUUoEAEQA/k8BAAIBRAABAAUATABJAFMAVAAxAAAAHAAQAAomAAtGEgAPhG4E
EYTl/hOkeAANxgQBaAEADABDShYAT0oEAFFKBAA0AP4P8QASATQAAAAKAFQARQBYAFQASQBOAEQA
RQBOAFQAAAAOABEAD4RmDhGE7fQTpHgAAAAAAAAAugkAAAoAACIAAAAA/////wAEAAC6DQAADAAA
AAAEAAChBwAARQoAALoNAAANAAAADwAAABAAAAAABAAAug0AAA4AAAAAAAAACQAAAAoAAAAOAAAA
DwAAABEAAAAXAAAAHAAAAB4AAAAiAAAAIwAAACUAAAAqAAAAMgAAADQAAAA5AAAAOwAAAEUAAACf
AAAAowAAALIAAAC4AAAAxwAAANIAAADpAAAA8AAAABYBAAAbAQAAUAEAAFYBAABYAQAAYQEAAGkB
AABxAQAAdQEAAH8BAACCAQAAiwEAAJ0BAAClAQAArwEAALQBAAC1AQAAwAEAAMEBAADJAQAA1wEA
AOIBAADwAQAA9QEAAAkCAAANAgAADgIAABMCAAAXAgAAHwIAACkCAAAuAgAALwIAADMCAAA0AgAA
PAIAAEYCAABLAgAATwIAAFUCAABoAgAAcwIAAI0CAACXAgAAmwIAAKECAACuAgAAuwIAAMwCAADS
AgAA5QIAAPICAAABAwAABwMAABwDAAAhAwAAIgMAACQDAAAlAwAAKwMAAD8DAABEAwAARQMAAE4D
AABbAwAAYAMAAGkDAABxAwAAfgMAAIgDAACXAwAAmgMAALoDAADCAwAAwwMAAMgDAADJAwAA0AMA
APMDAAD5AwAA+gMAAAkEAAAYBAAAHgQAADQEAAA4BAAATQQAAFIEAABTBAAAWAQAAGsEAAByBAAA
/QQAAAcFAAAYBQAAIAUAACYFAAAsBQAAPgUAAEsFAABMBQAAVQUAAFYFAABlBQAAlAUAAJ4FAADK
BQAAzgUAAM8FAADdBQAA6AUAAPAFAADxBQAA9AUAAB4GAAAhBgAAMQYAAD8GAABgBgAAawYAAG0G
AABzBgAAdAYAAHgGAAA6BwAAUAcAAF4HAABnBwAAaQcAAHcHAACgBwAAqQcAAPMHAAD8BwAAPggA
AEUIAABGCAAATwgAAGMIAABtCAAAcQgAAHYIAAB/CAAAhwgAAIgIAACNCAAA2ggAAOEIAADiCAAA
6QgAAPQIAAD+CAAAAgkAAAgJAAAXCQAAHgkAADQJAAA5CQAAOgkAAEAJAABKCQAAUwkAAIUJAACM
CQAAjQkAAJEJAACTCQAAlwkAAJgJAACcCQAAnQkAAKUJAAC8CQAAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH
ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc
AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH
ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA//8GAAAAEQBHAHIA/ABuAGUAbgBm
AGUAbABkAGUAcgAgAFIAZQB0AG8AKABcAFwAQQBSADEAMQBTADAAMAAxAFwAQwBNAEkARABFAEEA
JABcAEsAVQBOAEQARQBOAFwAcgBlAGYAZQByAGUAbgB6AGUAbgAuAGQAbwBjAA4AUwB0AGUAcABo
AGEAbgAgAFQAZQBpAHcAZQBzADsAQwA6AFwAVABFAE0AUABcAEEAdQB0AG8AVwBpAGUAZABlAHIA
aABlAHIAcwB0AGUAbABsAGUAbgAtAFMAcABlAGkAYwBoAGUAcgB1AG4AZwAgAHYAbwBuACAAcgBl
AGYAZQByAGUAbgB6AGUAbgAuAGEAcwBkAA4AUwB0AGUAcABoAGEAbgAgAFQAZQBpAHcAZQBzADEA
XABcAEEAUgAxADEAUwAwADAAMQBcAGUAdABlAGkAdwBzACQAXABEAGEAdABlAG4AXABTAE0ASQBN
AEUAXAByAGUAZgBlAHIAZQBuAHoAZQBuAEkARABFAEEALgBkAG8AYwABAP88LnXA0FrL/w8AAAAA
AAAAAAAAAAAAAAAAAQABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgB
Bk9KAQBRSgEAbygAAQC38AEAAAD/PC51AAAAAAAAAAAAAAAA////////AQAAAAAA/0ADgAEAAAAA
AAAAAAD8OUADAQA5AAAAAAAAAAAAAAAAAAAAAAACEAAAAAAAAAC6CQAAoAAACABAAAAFAAAARxaQ
AQAAAgIGAwUEBQIDBIcCAAAAAAAAAAAAAAAAAACfAAAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAA
UgBvAG0AYQBuAAAANRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBt
AGIAbwBsAAAAMyaQAQAAAgsGBAICAgICBIcCAAAAAAAAAAAAAAAAAACfAAAAAAAAAEEAcgBpAGEA
bAAAAD8GkAEAAAAAAAAAAAAAAACHAAAAAAAAAAAAAAAAAAAAGwAAAAAAAABGAHIAdQB0AGkAZwBl
AHIAIAA2ADUAAAA/BpABAAAAAAAAAAAAAAAAhwAAAAAAAAAAAAAAAAAAABsAAAAAAAAARgByAHUA
dABpAGcAZQByACAANAA1AAAAIgAEAHEIiBgAAMQCAACpAQAAAABrMzRGazM0RgAAAAACAAAAAABo
AQAABQgAAAEABAAAAAQAAxARAAAAAAAAAAAAAAABAAEAAAABAAAAAAAAACEDAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAKUGwAe0ALQAgAASMAAAAAAAAAAAAAAAAAAA2QkAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC
AAAAAAD//xIAAAAAAAAAFgBCAGEAbgBrAGUAbgAsACAAVgBlAHIAcwBpAGMAaABlAHIAdQBuAGcA
ZQBuAAAAAAAAABEARwByAPwAbgBlAG4AZgBlAGwAZABlAHIAIABSAGUAdABvAA4AUwB0AGUAcABo
AGEAbgAgAFQAZQBpAHcAZQBzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQAAgAAAAAAAAAAAAAAAAAAAAAAAQAA
AOCFn/L5T2gQq5EIACsns9kwAAAAaAEAAA8AAAABAAAAgAAAAAIAAACIAAAAAwAAAKgAAAAEAAAA
tAAAAAUAAADQAAAABwAAANwAAAAIAAAA8AAAAAkAAAAIAQAAEgAAABQBAAAMAAAAMAEAAA0AAAA8
AQAADgAAAEgBAAAPAAAAUAEAABAAAABYAQAAEwAAAGABAAACAAAA5AQAAB4AAAAXAAAAQmFua2Vu
LCBWZXJzaWNoZXJ1bmdlbgAAHgAAAAEAAAAAYW5rHgAAABIAAABHcvxuZW5mZWxkZXIgUmV0bwBu
Zx4AAAABAAAAAHL8bh4AAAALAAAATm9ybWFsLmRvdAByHgAAAA8AAABTdGVwaGFuIFRlaXdlcwB0
HgAAAAIAAAAyAGVwHgAAABMAAABNaWNyb3NvZnQgV29yZCA4LjAAZ0AAAAAA+iGfIoC+AUAAAAAA
+iGfIoC+AQMAAAABAAAAAwAAAGgBAAADAAAABQgAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4b
EJOXCAArLPmuRAAAAAXVzdWcLhsQk5cIACss+a5IAQAABAEAAAwAAAABAAAAaAAAAA8AAABwAAAA
BQAAAIAAAAAGAAAAiAAAABEAAACQAAAAFwAAAJgAAAALAAAAoAAAABAAAACoAAAAEwAAALAAAAAW
AAAAuAAAAA0AAADAAAAADAAAAOMAAAACAAAA5AQAAB4AAAAGAAAAQXNjb20AIAADAAAAEQAAAAMA
AAAEAAAAAwAAANkJAAADAAAA6BAIAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAA
AAEAAAAXAAAAQmFua2VuLCBWZXJzaWNoZXJ1bmdlbgAMEAAAAgAAAB4AAAAGAAAAVGl0ZWwAAwAA
AAEAAAAAAACYAAAAAwAAAAAAAAAgAAAAAQAAADYAAAACAAAAPgAAAAEAAAACAAAACgAAAF9QSURf
R1VJRAACAAAA5AQAAEEAAABOAAAAewA4AEUANwAxADQAOQA4ADQALQBFAEIARQBFAC0AMQAxAEQA
MgAtADgAMQAwADEALQAwADAAOAAwAEMANwAzAEYARQA0AEQARgB9AAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAA
AAwAAAANAAAADgAAAA8AAAAQAAAAEQAAAP7///8TAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAA
/v///xsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAD+////IwAAACQAAAAlAAAAJgAAACcAAAAo
AAAAKQAAAP7////9////LAAAAP7////+/////v//////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA/QAfAAAADAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAAAACn
4HSiIoC+ASAlcqQigL4BLgAAAIAAAAAAAAAAMQBUAGEAYgBsAGUAAAAAAIB/FgAAAAAAAAAAAAEA
AAAUAAAAEAAAABAAAAAXAAAAFgAAAAAAAAAAAAAAAgAAAA4AAgD///////////////8HAAAABgAA
AAQAAAAEAAAA//////////8AAAAAAAAAAAAAAAASAAAAABAAAAAAAP9XAG8AcgBkAEQAbwBjAHUA
bQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAUYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQUAAAD/
/////////+iWGQBAkRkAFgAAAAQAAAAQAAAAEAAAAAQAAAD/AAAA/////wAAAAAeIgAAAQAAAAUA
UwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAD/////////////////////////
//////8oAAIBAgAAAAQAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
GgAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBh
AHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAiAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAQEAAAAGAAAA/////wAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAE8AYgBqAGUAYwB0AFAAbwBv
AGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEA////////
////////AAAAAAAAAAAAAAAAAAAAAAAAAAAgJXKkIoC+ASAlcqQigL4BAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAABAAAA/v//////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0IFdvcmQt
RG9rdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAA

------ =_NextPart_000_01BE8022.A2E1A7A0--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA22063 for ietf-smime-bks; Mon, 5 Apr 1999 04:45:06 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA22059 for <[e-mail]>; Mon, 5 Apr 1999 04:45:04 -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 HAA27299; Mon, 5 Apr 1999 07:45:03 -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-cmskea-00.txt
Date: Mon, 05 Apr 1999 07:45:02 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
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		: CMS KEA and SKIPJACK Conventions
	Author(s)	: J. Prawling
	Filename	: draft-ietf-smime-cmskea-00.txt
	Pages		: 10
	Date		: 02-Apr-99
	
This document describes the conventions for using the Key Exchange 
Algorithm (KEA) and SKIPJACK encryption algorithm in conjunction with the Cryptographic Message Syntax [CMS] enveloped-data and encrypted-data 
content types.

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

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA14281 for ietf-smime-bks; Fri, 2 Apr 1999 14:48:10 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA14276 for <[e-mail]>; Fri, 2 Apr 1999 14:48:09 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06103; Fri, 2 Apr 1999 17:16:53 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-msg-07.txt
Date: Fri, 02 Apr 1999 17:16:52 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: S/MIME Version 3 Message Specification
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-msg-07.txt
	Pages		: 27
	Date		: 01-Apr-99
	
S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a
consistent way to send and receive secure MIME data. Based on the
popular Internet MIME standard, S/MIME provides the following
cryptographic security services for electronic messaging applications:
authentication, message integrity and non-repudiation of origin (using
digital signatures) and privacy and data security (using encryption).
 
S/MIME can be used by traditional mail user agents (MUAs) to add
cryptographic security services to mail that is sent, and to interpret
cryptographic security services in mail that is received. However,
S/MIME is not restricted to mail; it can be used with any transport
mechanism that transports MIME data, such as HTTP. As such, S/MIME
takes advantage of the object-based features of MIME and allows secure
messages to be exchanged in mixed-transport systems.
 
Further, S/MIME can be used in automated message transfer agents that
use cryptographic security services that do not require any human
intervention, such as the signing of software-generated documents and
the encryption of FAX messages sent over the Internet.

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

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA14277 for ietf-smime-bks; Fri, 2 Apr 1999 14:48:09 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA14272 for <[e-mail]>; Fri, 2 Apr 1999 14:48:08 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06117; Fri, 2 Apr 1999 17:16:59 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-cert-07.txt
Date: Fri, 02 Apr 1999 17:16:58 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: S/MIME Version 3 Certificate Handling
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-cert-07.txt
	Pages		: 11
	Date		: 01-Apr-99
	
S/MIME (Secure/Multipurpose Internet Mail Extensions), described in
[SMIME-MSG], provides a method to send and receive secure MIME
messages. Before using a public key to provide security services, the
S/MIME agent MUST certify that the public key is valid. S/MIME agents
MUST use PKIX certificates to validate public keys as described in the
Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL
Profile [KEYM].  S/MIME agents MUST meet the S/MIME-specific
requirements documented in this I-D in addition to those stated in
[KEYM].
 
This specification is compatible with the Cryptographic Message Syntax
[CMS] in that it uses the data types defined by CMS. It also inherits
all the varieties of architectures for certificate-based key
management supported by CMS. Note that the method S/MIME messages make
certificate requests is defined in [SMIME-MSG].

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

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA02142 for ietf-smime-bks; Thu, 1 Apr 1999 10:46:18 -0800 (PST)
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA02138 for <[e-mail]>; Thu, 1 Apr 1999 10:46:16 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.32 (Beta)
Date: Thu, 01 Apr 1999 10:45:31 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-smime-idea-00.txt
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-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have a few objections to this draft that I would like to see cleared up 
before any further discussion happens on the draft.

The draft does not have the mandatory notice about whether or not it 
complies with RFC 2026. Without this notice, the authors could claim that 
they do not release copyright on the draft to the IETF, and therefore we 
may not be able to use the discussions of the draft in the future.

The draft seems more like a marketing effort than a technical 
specification. All the talk about integration with S/MIME, the history of 
IDEA, and so on is pretty useless. A simple document saying "here's the 
OID, here are the parameters, here's our patent statement" would suffice. 
(I find it particularly galling that the sentence "S/MIME is constructed as 
an open system." is used near the beginning of the draft as a way to make 
nice before proposing an algorithm that is heavily protected by patents.)

The draft restates some of the MUSTs and SHOULDs from the -msg draft, which 
is completely inappropriate. All such restatements should be removed, 
leaving just the changes that this draft would make to the 
hopefully-soon-to-be-standard.

There is no Security Considerations section; I think one would be 
appropriate, given that this is proposing an algorithm that is not widely 
known.

The statement "Commercial licenses can be obtained by contacting 
[e-mail]" is interesting, if true. I was told a few years ago that a 
company that applied for an IDEA license for PGP was flatly rejected 
without any talk of the cost (I have no verification of this). Perhaps the 
authors of this draft should reword the sentence, or spell out what they 
mean in terms similar to those used in RFC 2026 and RFC 2028.


--Paul Hoffman, Director
--Internet Mail Consortium