RE: I-D ACTION:draft-ietf-smime-pss-00.txt

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

Francois,

I agree that a comment on not using the same RSA key pair for both RSA
PKCS#1 v1.5 and RSA-PSS is a good idea and will insert this.

I do not believe that there is a strong argument for creating an
SMIMECapability for RSA-PSS, but would welcome comments from the list.
The reason that I don't believe that it is really needed is that the
worst that happens is you send a message to somebody and the recipient
cannot validate the signature.  However, I do not know of any MUAs that
look at SMIMECapabilities for sending signed messages.  This is not the
same problem as with encrypted mail where there is no way to see the
message if the client does not understand the content encryption
algorithm.

I am hesitant to try and address issues of hash sizes with any degree of
specifics.  Given the amount of arguments over
draft-orman-public-key-lengths-05.txt I don't want to follow the rat
down the hole.  Do you see any need for text beyond that in
draft-ietf-pkix-rsa-pkalgs-00.txt?

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> Sent: Wednesday, February 26, 2003 9:32 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: RE: I-D ACTION:draft-ietf-smime-pss-00.txt
> 
> 
> 
> Hi Jim,
> 
> I understand that this Internet Draft is much simpler than 
> the one on the
> use of RSA-OAEP under CMS since you are referring to a future 
> PKIX RFC (i.e.
> RSA-ALGS).
> 
> However, I would think it still needs to include a separate section on
> SMIMECapabilities attribute conventions addressing the various hash
> functions, and the section on security considerations should 
> probably touch
> on not using of the same RSA private key under both RSA PKCS 
> #1 v1.5 and
> RSA-PSS, and on the choice of hash function and key sizes.
> 
> Cheers,
> 
> Francois
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, February 26, 2003 9:02 AM
> Cc: [e-mail]
> Subject: I-D ACTION:draft-ietf-smime-pss-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the S/MIME Mail Security Working 
> Group of the
> IETF.
> 
> 	Title		: Use of the PSS Signature Algorithm in CMS
> 	Author(s)	: J. Schaad
> 	Filename	: draft-ietf-smime-pss-00.txt
> 	Pages		: 5
> 	Date		: 2003-2-25
> 	
> This document specifies the conventions for using the RSA 
> Probabilistic Signature Scheme (RSASSA-PSS) digital signature 
> algorithm [P1v2.1] with the Cryptographic Message Syntax (CMS) [CMS].
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-smime-pss-00.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body 
> of the message.
> 
> 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-pss-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-pss-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.
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1S2WEu14855 for ietf-smime-bks; Thu, 27 Feb 2003 18:32:14 -0800 (PST)
Received: from mx4.pacifier.net (mx4.pacifier.net [64.255.237.184]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1S2WDY14851 for <[e-mail]>; Thu, 27 Feb 2003 18:32:13 -0800 (PST)
Received: from smtp1.pacifier.net (smtp1 [64.255.237.171]) by mx4.pacifier.net (Postfix) with ESMTP id EF90F6AAF9; Thu, 27 Feb 2003 18:32:16 -0800 (PST)
Received: from revelation (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id 55AAF6EF29; Thu, 27 Feb 2003 18:32:15 -0800 (PST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-pss-00.txt
Date: Thu, 27 Feb 2003 18:29:48 -0800
Message-ID: <001001c2ded1$44987b10$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Francois,

I agree that a comment on not using the same RSA key pair for both RSA
PKCS#1 v1.5 and RSA-PSS is a good idea and will insert this.

I do not believe that there is a strong argument for creating an
SMIMECapability for RSA-PSS, but would welcome comments from the list.
The reason that I don't believe that it is really needed is that the
worst that happens is you send a message to somebody and the recipient
cannot validate the signature.  However, I do not know of any MUAs that
look at SMIMECapabilities for sending signed messages.  This is not the
same problem as with encrypted mail where there is no way to see the
message if the client does not understand the content encryption
algorithm.

I am hesitant to try and address issues of hash sizes with any degree of
specifics.  Given the amount of arguments over
draft-orman-public-key-lengths-05.txt I don't want to follow the rat
down the hole.  Do you see any need for text beyond that in
draft-ietf-pkix-rsa-pkalgs-00.txt?

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> Sent: Wednesday, February 26, 2003 9:32 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: RE: I-D ACTION:draft-ietf-smime-pss-00.txt
> 
> 
> 
> Hi Jim,
> 
> I understand that this Internet Draft is much simpler than 
> the one on the
> use of RSA-OAEP under CMS since you are referring to a future 
> PKIX RFC (i.e.
> RSA-ALGS).
> 
> However, I would think it still needs to include a separate section on
> SMIMECapabilities attribute conventions addressing the various hash
> functions, and the section on security considerations should 
> probably touch
> on not using of the same RSA private key under both RSA PKCS 
> #1 v1.5 and
> RSA-PSS, and on the choice of hash function and key sizes.
> 
> Cheers,
> 
> Francois
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, February 26, 2003 9:02 AM
> Cc: [e-mail]
> Subject: I-D ACTION:draft-ietf-smime-pss-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the S/MIME Mail Security Working 
> Group of the
> IETF.
> 
> 	Title		: Use of the PSS Signature Algorithm in CMS
> 	Author(s)	: J. Schaad
> 	Filename	: draft-ietf-smime-pss-00.txt
> 	Pages		: 5
> 	Date		: 2003-2-25
> 	
> This document specifies the conventions for using the RSA 
> Probabilistic Signature Scheme (RSASSA-PSS) digital signature 
> algorithm [P1v2.1] with the Cryptographic Message Syntax (CMS) [CMS].
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-smime-pss-00.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body 
> of the message.
> 
> 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-pss-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-pss-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.
> 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QHQ7s14848 for ietf-smime-bks; Wed, 26 Feb 2003 09:26:07 -0800 (PST)
Received: from broadsword.its.cse.dnd.ca (itsfw.cse.dnd.ca [131.136.196.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QHQ5d14844 for <[e-mail]>; Wed, 26 Feb 2003 09:26:05 -0800 (PST)
Received: by broadsword.its.cse.dnd.ca with Internet Mail Service (5.5.2653.19) id <FMS6N5RS>; Wed, 26 Feb 2003 12:31:37 -0500
Message-ID: <[e-mail]>
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-smime-pss-00.txt
Date: Wed, 26 Feb 2003 12:31:36 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Jim,

I understand that this Internet Draft is much simpler than the one on the
use of RSA-OAEP under CMS since you are referring to a future PKIX RFC (i.e.
RSA-ALGS).

However, I would think it still needs to include a separate section on
SMIMECapabilities attribute conventions addressing the various hash
functions, and the section on security considerations should probably touch
on not using of the same RSA private key under both RSA PKCS #1 v1.5 and
RSA-PSS, and on the choice of hash function and key sizes.

Cheers,

Francois


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, February 26, 2003 9:02 AM
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-pss-00.txt


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

	Title		: Use of the PSS Signature Algorithm in CMS
	Author(s)	: J. Schaad
	Filename	: draft-ietf-smime-pss-00.txt
	Pages		: 5
	Date		: 2003-2-25
	
This document specifies the conventions for using the RSA 
Probabilistic Signature Scheme (RSASSA-PSS) digital signature 
algorithm [P1v2.1] with the Cryptographic Message Syntax (CMS) [CMS].

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QE5h602894 for ietf-smime-bks; Wed, 26 Feb 2003 06:05:43 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QE5fd02890 for <[e-mail]>; Wed, 26 Feb 2003 06:05:42 -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 JAA05358; Wed, 26 Feb 2003 09:01:47 -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-pss-00.txt
Date: Wed, 26 Feb 2003 09:01:47 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Use of the PSS Signature Algorithm in CMS
	Author(s)	: J. Schaad
	Filename	: draft-ietf-smime-pss-00.txt
	Pages		: 5
	Date		: 2003-2-25
	
This document specifies the conventions for using the RSA 
Probabilistic Signature Scheme (RSASSA-PSS) digital signature 
algorithm [P1v2.1] with the Cryptographic Message Syntax (CMS) [CMS].

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1ONqfQ06046 for ietf-smime-bks; Mon, 24 Feb 2003 15:52:41 -0800 (PST)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1ONqed06036 for <[e-mail]>; Mon, 24 Feb 2003 15:52:40 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: v2.2 S/MIME Freeware Library (SFL) Now Available
Date: Mon, 24 Feb 2003 18:52:42 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: v2.2 S/MIME Freeware Library (SFL) Now Available
Thread-Index: AcI5hhsP6XOt1UY5R2CHe/iQEv/4vw==
From: "Pawling, John" <[e-mail]>
To: "SMIME WG (SMIME WG)" <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1ONqed06038
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

DigitalNet (formerly Getronics Government Solutions) has delivered the
Version 2.2 S/MIME Freeware Library (SFL) source code.  The SFL source
code files and documents are freely available at 
<http://www.digitalnet.com/hot/sfl_home.htm>.  

The SFL implements the IETF S/MIME v3 RFC 3369 Cryptographic Message 
Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS)
specifications.
It implements portions of the RFC 2633 Message Specification, RFC 2632
Certificate Handling, and RFC 3370 CMS Algorithms specifications.  When
used in conjunction with the Crypto++ freeware library, the SFL 
implements the RFC 2631 Diffie-Hellman (D-H) Key Agreement Method 
specification.  It has been successfully tested using the Microsoft (MS)

Windows 2000/XP, Linux and Sun Solaris 2.8 operating systems.  Further 
enhancements, ports and testing of the SFL are still in process.  
Further releases of the SFL will be provided as significant 
capabilities are added. 

The SFL has been successfully used to sign, verify, encrypt and decrypt 
CMS/ESS objects using: DSA, E-S D-H, 3DES algorithms provided by the 
Crypto++ library; RSA suite of algorithms provided by the RSA BSAFE 6.0
Crypto-C and Crypto++ libraries; and Fortezza suite of algorithms 
provided by the Fortezza Crypto Card.  The v2.2 SFL uses the v2.2 
Certificate Management Library (CML) and v1.5 Enhanced SNACC (eSNACC) 
ASN.1 C++ Library to encode/decode objects.  The v2.2 SFL release 
includes: SFL High-level library; Free (a.k.a. Crypto++) Crypto Token
Interface Library (CTIL); BSAFE CTIL; Fortezza CTIL; SPEX/ CTIL; 
PKCS #11 CTIL; Microsoft CAPI v2.0 CTIL; test utilities; test drivers;
and test data.  All CTILs were tested as Dynamically Linked Libraries
(DLL) using MS Windows.  The Fortezza, BSAFE and Crypto++ CTILs
were tested with the respective security libraries as shared objects
using Linux and Solaris 2.8.  

The SFL has been successfully used to exchange signedData and 
envelopedData messages with the MS Internet Explorer Outlook Express 
v4.01, Netscape Communicator 4.X, Entrust and Baltimore S/MIME 
products.  Signed messages have been exchanged with the RSA S/MAIL and 
WorldTalk S/MIME v2 products. 

The SFL has also been used to perform S/MIME v3 interoperability 
testing with Microsoft that exercised the majority of the features 
specified by RFCs 3369, 3370, 2631 and 2634.  This testing included the
RSA, DSA, E-S D-H, 3DES, SHA and Fortezza algorithms.  We used the SFL 
to successfully process the SFL-supported sample data included in the
S/MIME WG "Examples of S/MIME Messages" document.  We also used the
SFL to generate S/MIME v3 sample messages that were included in the 
"Examples" document.

The use of the v2.2 SFL is described in the v2.2 SFL Application 
Programming Interface (API) and v2.2 SFL Software Design Description
documents.  The use of the v2.2 CTIL API is described in the v2.2
CTIL API document. 


v2.2 SFL includes the following enhancements (compared to v2.1
SFL and CTIL releases):
 
1) Enhanced SFL to optionally make internal calls to the freeware
Access Control Library (ACL) to perform SDN.801 access control checks. 

2) Enhanced SignedData processing to input and process X.509 (2000) 
v2 Attribute Certificates.

3) Increased performance for Mail List Agents by providing ability
to build an envelopedData without needing to re-encrypt the content
extracted from the received envelopedData. 

4) Enhanced SFL to facilitate use of multiple GeneralName instances
(i.e. e-mail address and DN) in a GeneralNames SEQUENCE.  This is
needed for the receipt request receiptTo field.

5) Added support to decode unrecognized elements of RFC 3369 
RecipientInfo syntax. 

6) Modified CSMIME login list container to remove "m_pCSInsts2" member.
The new logic now references the CSM_CtilMgr::m_pCSInsts list
(CSM_CtilInst, no certificates).



v2.2 CTILs include the following enhancements (compared to
v2.1 release):

1) CSM_Buffer moved into CTILMgr. 

2) Added CSM_Buffer capability to decode and copy to another buffer.

3) Enhanced Crypto++ CTIL to use either Crypto++ v5.0 or v4.2.



v2.2 CertificateBuilder utility (to be delivered by 28 February 2003)
includes the following enhancements (compared to v2.1 release):

1) Improved capability to generate X.509 (2000) Attribute Certificates
including X.501 Clearance attributes including user-selected values 
extracted from Security Policy Information File (SPIF) for the
security policy.  


We are still in the process of enhancing and testing the SFL.  Future 
releases may include: additional PKCS #11 CTIL testing;  
add "Certificate Management Messages over CMS" ASN.1 encode/decode 
functions; add enhanced test routines; bug fixes; and support for
other operating systems. 

The SFL is developed to maximize portability to 32-bit operating 
systems.  In addition to testing on MS Windows, Linux and Solaris 2.8, 
we may port the SFL to other operating systems.

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

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

The SFL is composed of a high-level library that performs generic CMS 
and ESS processing independent of the crypto algorithms used to 
protect a specific object.  The SFL high-level library makes calls to 
an algorithm-independent CTIL API.  The underlying, external crypto
token libraries are not distributed as part of the SFL source code. 
The application developer must independently obtain these libraries and
then link them with the SFL.  
 
The SFL uses the CML and eSNACC ASN.1 Library to encode/decode
certificates, ACs, CRLs and components thereof.  The CML is freely
available at: <http://www.DigitalNet.com/hot/cml_home.htm>.

The SFL has been successfully tested in conjunction with the Access
Control Library (ACL) that is freely available to everyone from: 
<http://www.DigitalNet.com/hot/acl_home.htm>.

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

NIST is using the SFL and CML as part of the NIST S/MIME Test 
Facility (NSMTF) that they are planning to host (see 
<http://csrc.ncsl.nist.gov/pki/smime/>).  Vendors will be able to use
the NSMTF to help determine if their products comply with the
IETF S/MIME v3 specifications and the Federal S/MIME v3 Client Profile. 

The SFL has been integrated into many applications to provide CMS/ESS
security services.  For example, the SFL was integrated into a security
plug-in for a commercial e-mail application that enabled the 
application to meet the Bridge Certification Authority Demonstration 
Phase II requirements including implementing ESS features such as
security labels.

The Internet Mail Consortium (IMC) has established an SFL web page
<http://www.imc.org/imc-sfl>.  The IMC has also established an SFL
mail list which is used to: distribute information regarding SFL
releases; discuss SFL-related issues; and provide a means for SFL
users to provide feedback, comments, bug reports, etc.  Subscription
information for the imc-sfl mailing list is at the IMC web site
listed above.

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

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


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OMXSL03102 for ietf-smime-bks; Mon, 24 Feb 2003 14:33:28 -0800 (PST)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OMXRd03097 for <[e-mail]>; Mon, 24 Feb 2003 14:33:27 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: v1.5 Enhanced SNACC Freeware Now Available
Date: Mon, 24 Feb 2003 17:33:29 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: v1.5 Enhanced SNACC Freeware Now Available
Thread-Index: AcI5cp6Z14OJyzHGQ8i472hAAgjQnA==
From: "Pawling, John" <[e-mail]>
To: "SMIME WG (SMIME WG)" <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1OMXRd03098
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

DigitalNet (formerly Getronics Government Solutions) has delivered 
the v1.5 eSNACC Abstract Syntax Notation.1 (ASN.1) Compiler, C++ 
library and C library source code compilable for Linux, Sun Solaris
2.8 and Microsoft (MS) Windows NT/98/2000/XP.  The eSNACC software 
is freely available to everyone from:
<http://www.digitalnet.com/hot/snacc_home.htm>

The eSNACC ASN.1 software can be used to ASN.1 encode and decode
objects.  In past releases, DigitalNet improved the eSNACC C++ 
library to implement the Distinguished Encoding Rules (DER), 
support large ASN.1 INTEGERs, and improve memory usage.    

v1.5 eSNACC enhancements (compared to v1.4 release):

1) Updated compiler to automatically read in ASN.1 module files
listed in IMPORTS section of primary module.  Added option for
specifying directories to search when looking for imported ASN.1
modules.  Now only primary ASN.1 module needs to be passed to 
the compiler.

2) Enhanced compiler to support OCTET STRING CONTAINS DER ENCODING
feature.

3) Enhanced AsnBuf, ASNOcts, ASNAny class to expand as necessary
when encoding and to decode directly from a file.  CSM_Buffer
moved out of eSNACC.  

4) Enhanced C Library to use GenBuf to provide improved buffer
processing capabilities. 


We successfully tested the v1.5 eSNACC ASN.1 C++ and C libraries
using the Simple Network Management Protocol (SNMP) v1 test
suite (18,000 test cases) developed by the University of Oulu.    

We tested the v1.5 eSNACC release with the v2.2 S/MIME
Freeware Library (SFL) available from 
<http://www.digitalnet.com/hot/sfl_home.htm> that 
uses the eSNACC ASN.1 software to encode and decode the IETF 
S/MIME v3 Cryptographic Message Syntax (RFC 3369) and Enhanced
Security Services for S/MIME (RFC 2634) security protocol.  

We tested the v1.5 eSNACC release with the freeware v2.2
Certificate Management Library (CML) available from
<http://www.digitalnet.com/hot/cml_home.htm> 
that uses the eSNACC ASN.1 software to encode and decode X.509 
certificates, attribute certificates and Certificate Revocation 
Lists as specified in the 2000 X.509 Recommendation.

We tested the v1.5 eSNACC release with the freeware v2.2 
Access Control Library (ACL) available from 
<http://www.digitalnet.com/hot/acl_home.htm>
that uses the eSNACC ASN.1 software to encode and decode security
labels and other objects (such as Security Policy Information 
Files) required to provide rule based automated access control 
as specified in SDN.801.

The eSNACC ASN.1 software implements the majority of the 
ASN.1 encoding/decoding rules as specified in the 1988 X.209 
Recommendation.  It implements the DER as specified in the 1997 
X.690 Recommendation.  It does not support all of the latest ASN.1
features, but there are strategies that allow it to be used to 
produce ASN.1 hex encodings that are identical to those produced by
ASN.1 libraries that do support the latest ASN.1 features.  Also note
that many of the PKIX specs, such as RFC 3280 and RFC 2630, include 
1988-compliant ASN.1 syntax modules which can be compiled using the
eSNACC compiler.

The eSNACC ASN.1 library is totally unencumbered as stated 
in the Enhanced SNACC Software Public License.  All source code
for the eSNACC software is being provided at no cost and with no
financial limitations regarding its use and distribution.  
Organizations can use the eSNACC software without paying
any royalties or licensing fees.  

The Internet Mail Consortium (IMC) has established an eSNACC
web page <http://www.imc.org/imc-snacc/>.  The IMC has established 
an eSNACC mail list which is used to: distribute information 
regarding eSNACC releases; discuss related issues; and 
provide a means for integrators to provide feedback, comments,
bug reports, etc.  Subscription information for the imc-snacc
mail list is at the IMC web site listed above.

We are still in the process of improving the eSNACC software.
We welcome all feedback regarding the eSNACC software.
If bugs are reported, then we will investigate each reported
bug and, if required, will produce a patch or an updated
release of the software to repair the bug. 

This release announcement was sent to several mail lists,
but please send all messages regarding the eSNACC 
software to the imc-snacc mail list ONLY.  Please do not send 
messages regarding the eSNACC software to any of the 
IETF mail lists.  We will respond to all messages sent to the
imc-snacc mail list.

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


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1LDiQq00604 for ietf-smime-bks; Fri, 21 Feb 2003 05:44:26 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1LDiPd00599 for <[e-mail]>; Fri, 21 Feb 2003 05:44:25 -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 IAA29163; Fri, 21 Feb 2003 08:40:35 -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-rfc2632bis-03.txt
Date: Fri, 21 Feb 2003 08:40:35 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: S/MIME Version 3.1 Certificate Handling
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-rfc2632bis-03.txt
	Pages		: 0
	Date		: 2003-2-20
	
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 certificate processing
requirements documented in this document 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-rfc2632bis-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-rfc2632bis-03.txt".

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KNGb508245 for ietf-smime-bks; Thu, 20 Feb 2003 15:16:37 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1KNGad08241 for <[e-mail]>; Thu, 20 Feb 2003 15:16:36 -0800 (PST)
Received: (qmail 16400 invoked from network); 20 Feb 2003 23:16:25 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (131.107.52.146) by woodstock.binhost.com with SMTP; 20 Feb 2003 23:16:25 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 20 Feb 2003 18:16:30 -0500
To: Holger Ebel <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: signatureAlgorithm in PKCS#7/RFC 2630/RFC 3369/70
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Holger:

PKCS#7 only supported the RSA algorithm, and it used field names that 
represent this situation.  signatureAlgorithm is the new name, indicating 
support for any digital signature algorithm.  The digestEncryptionAlgorithm 
is the old name, indicating the RSA operation that is performed to generate 
a digital signature with that algorithm.

<snip>

>Now my questions:
>
>(2) How should I handle a CMS (2630/3369) signature where the value of
>     the digestAlgorithm does not match the 'included' digestAlgorithm in
>     the signatureAlgorithm field. (e.g. having a RIPEMD160 digestAlgo
>     OID at the digestInfo field and a Sha1WithDSA OID in the signature-
>     algorithm field).

I think that the digestAlgorithm must be consistent with the one used in 
the signature.

>(3) When a component claims that it can produce valid RFC 2630
>     signatures, is the usage of the 'old' RSA OID 1.2.840.113549.1.1.1
>     the only exception from the rule? Is the usage of the 'other'
>     RSA signature OIDs (sha1WithRSAEncryption) really forbidden in 2630?

Be flexible in receive processing, but strict on send processing.  That 
said, if you need interoperability with some PKCS#7 implementations, you 
may need to send it the only way that they know how to accept it.

Russ 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1K1Cr915305 for ietf-smime-bks; Wed, 19 Feb 2003 17:12:53 -0800 (PST)
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1K1Cqd15301 for <[e-mail]>; Wed, 19 Feb 2003 17:12:52 -0800 (PST)
Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Wed, 19 Feb 2003 17:12:50 -0800
From: "Blake Ramsdell" <[e-mail]>
To: "'Trevor Freeman'" <[e-mail]>, <[e-mail]>, "'Jim Schaad'" <[e-mail]>
Subject: RE: Extended Key Usage extension and S/MIME
Date: Wed, 19 Feb 2003 17:12:50 -0800
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> -----Original Message-----
> From: Trevor Freeman [mailto:[e-mail]] 
> Sent: Wednesday, February 19, 2003 4:45 PM
> To: Blake Ramsdell; [e-mail]
> Subject: RE: Extended Key Usage extension and S/MIME
> 
> RFC3280 requires a client who understands an extension to 
> implement its
> contents regardless of the criticality flag. The critical flag tells a
> client who don't understand that extension if it they can use the cert
> or not. 

This is consistent with Jim's comment also, and I agree that I was
misinterpreting the field.

> If the extended key usage extension is present and the client 
> implements
> the extension, and it does not contain at least one of the
> anyExtendedKeyUsage or the emailProtection key purpose Ids, then the
> certificate is not considered suitable for verifying signatures or key
> management.  Otherwise,
> continue with normal certificate processing.

OK, I'm proceeding with this.  Any controversy around the
"anyExtendedKeyUsage" purpose?

Blake



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1K0jGG14779 for ietf-smime-bks; Wed, 19 Feb 2003 16:45:16 -0800 (PST)
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1K0jEd14775 for <[e-mail]>; Wed, 19 Feb 2003 16:45:14 -0800 (PST)
Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Wed, 19 Feb 2003 16:45:17 -0800
Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 19 Feb 2003 16:45:10 -0800
Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Wed, 19 Feb 2003 16:45:18 -0800
Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 19 Feb 2003 16:45:15 -0800
Received: from WIN-MSG-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Wed, 19 Feb 2003 16:45:11 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Extended Key Usage extension and S/MIME
Date: Wed, 19 Feb 2003 16:45:03 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Extended Key Usage extension and S/MIME
Thread-Index: AcLYcood4uhDbv3XQEODfLSIKqe9yAABWtZQ
From: "Trevor Freeman" <[e-mail]>
To: "Blake Ramsdell" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 20 Feb 2003 00:45:11.0060 (UTC) FILETIME=[52BDAD40:01C2D879]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1K0jFd14776
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Blake,
RFC3280 requires a client who understands an extension to implement its
contents regardless of the criticality flag. The critical flag tells a
client who don't understand that extension if it they can use the cert
or not. 

So

If the extended key usage extension is present and the client implements
the extension, and it does not contain at least one of the
anyExtendedKeyUsage or the emailProtection key purpose Ids, then the
certificate is not considered suitable for verifying signatures or key
management.  Otherwise,
continue with normal certificate processing.

If you don't understand the extension then you are simply following the
criticality flag so there is no specific behaviour required by S/MIME in
this case except beyond what's in 3280.

Trevor

-----Original Message-----
From: Blake Ramsdell [mailto:[e-mail]] 
Sent: Wednesday, February 19, 2003 3:45 PM
To: [e-mail]
Subject: Extended Key Usage extension and S/MIME


I received a request to include language regarding the extended key
usage certificate extension in the next version of the CERT draft.

It seems that the language is basically:

If the extended key usage extension is present and marked critical, and
it does not contain at least one of the anyExtendedKeyUsage or the
emailProtection key purpose Ids, then the certificate is not considered
suitable for verifying signatures or key management.  Otherwise,
continue with normal certificate processing.

So the point is that if:

1. The extension is present and not marked critical, and doesn't contain
emailProtection or anyExtendedKeyUsage, no one cares because it isn't
critical, and processing continues

2. The extension is present and marked critical and doesn't contain
emailProtection or anyExtendedKeyUsage, it's rejected

3. If it's not present, then processing continues

Anyone have any understanding of the current use of this extension, so
that we might have some assurance that this is the right way to move
forward, or is that outside the scope of this?

Blake
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1K0YAc14602 for ietf-smime-bks; Wed, 19 Feb 2003 16:34:10 -0800 (PST)
Received: from mx1.pacifier.net (mx1.pacifier.net [64.255.237.181]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1K0Y9d14598 for <[e-mail]>; Wed, 19 Feb 2003 16:34:09 -0800 (PST)
Received: from smtp3.pacifier.net (smtp3 [64.255.237.173]) by mx1.pacifier.net (Postfix) with ESMTP id 0CADB6A7B0; Wed, 19 Feb 2003 16:34:12 -0800 (PST)
Received: from revelation (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp3.pacifier.net (Postfix) with ESMTP id 3B1316D62D; Wed, 19 Feb 2003 16:34:11 -0800 (PST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Blake Ramsdell'" <[e-mail]>, <[e-mail]>
Subject: RE: Extended Key Usage extension and S/MIME
Date: Wed, 19 Feb 2003 16:32:01 -0800
Message-ID: <001e01c2d877$7cd69260$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAA0infGMObH0W/[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Blake,

I disagree with the non-critical interperation.  I believe that it
SHOULD be respected even if the extension is not marked critical.

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Blake Ramsdell
> Sent: Wednesday, February 19, 2003 3:45 PM
> To: [e-mail]
> Subject: Extended Key Usage extension and S/MIME
> 
> 
> 
> I received a request to include language regarding the extended key
> usage certificate extension in the next version of the CERT draft.
> 
> It seems that the language is basically:
> 
> If the extended key usage extension is present and marked 
> critical, and
> it does not contain at least one of the anyExtendedKeyUsage or the
> emailProtection key purpose Ids, then the certificate is not 
> considered
> suitable for verifying signatures or key management.  Otherwise,
> continue with normal certificate processing.
> 
> So the point is that if:
> 
> 1. The extension is present and not marked critical, and 
> doesn't contain
> emailProtection or anyExtendedKeyUsage, no one cares because it isn't
> critical, and processing continues
> 
> 2. The extension is present and marked critical and doesn't contain
> emailProtection or anyExtendedKeyUsage, it's rejected
> 
> 3. If it's not present, then processing continues
> 
> Anyone have any understanding of the current use of this extension, so
> that we might have some assurance that this is the right way to move
> forward, or is that outside the scope of this?
> 
> Blake
> --
> Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com 
> 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1JNiaM13501 for ietf-smime-bks; Wed, 19 Feb 2003 15:44:36 -0800 (PST)
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1JNiZd13497 for <[e-mail]>; Wed, 19 Feb 2003 15:44:35 -0800 (PST)
Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Wed, 19 Feb 2003 15:44:33 -0800
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>
Subject: Extended Key Usage extension and S/MIME
Date: Wed, 19 Feb 2003 15:44:33 -0800
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAA0infGMObH0W/[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I received a request to include language regarding the extended key
usage certificate extension in the next version of the CERT draft.

It seems that the language is basically:

If the extended key usage extension is present and marked critical, and
it does not contain at least one of the anyExtendedKeyUsage or the
emailProtection key purpose Ids, then the certificate is not considered
suitable for verifying signatures or key management.  Otherwise,
continue with normal certificate processing.

So the point is that if:

1. The extension is present and not marked critical, and doesn't contain
emailProtection or anyExtendedKeyUsage, no one cares because it isn't
critical, and processing continues

2. The extension is present and marked critical and doesn't contain
emailProtection or anyExtendedKeyUsage, it's rejected

3. If it's not present, then processing continues

Anyone have any understanding of the current use of this extension, so
that we might have some assurance that this is the right way to move
forward, or is that outside the scope of this?

Blake
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1IAo7N27808 for ietf-smime-bks; Tue, 18 Feb 2003 02:50:07 -0800 (PST)
Received: from xenox.inexnet.de (tach-auch.inexnet.de [217.113.32.61] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1IAo5d27804 for <[e-mail]>; Tue, 18 Feb 2003 02:50:05 -0800 (PST)
Received: from gate.wisnet.de (gate.wisnet.de [213.61.157.73]) by xenox.inexnet.de (8.9.0/8.9.0) with ESMTP id EAA25369 for <[e-mail]>; Sun, 23 Feb 2003 04:34:16 +0100
Received: from authentidate.de (input.authentidate.de [192.168.42.73]) by gate.wisnet.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h1IAnx912530; Tue, 18 Feb 2003 11:49:59 +0100
X-Authentication-Warning: gate.wisnet.de: Host input.authentidate.de [192.168.42.73] claimed to be authentidate.de
Message-ID: <[e-mail]>
Date: Tue, 18 Feb 2003 11:50:15 +0100
From: Holger Ebel <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: Holger Ebel <[e-mail]>
Subject: signatureAlgorithm in PKCS#7/RFC 2630/RFC 3369/70
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[I accidentally posted this (somewhat different) message to the pkix
list, apologize for that. After some direct replies I've modified
some parts of my original post]

Hello,

after working through these specs and decoding many example signatures
I still have the following questions regarding the meaning of the
signatureAlgorithm/digestEncryptionAlgorithm in these standards
mentioned above. (To be more precise, the appearance of these in the
SignerInfo structure of the SignedData contentType)

If this topic does not belong to this list, it would be nice if someone
can point me at the responsible mailing list.

Please note that I use the term signatureAlgorithm for the combination
of a digest and a digestEncryption algorithm in the following mail.

With respect, I would like to summarize first how I get these standards.

- PKCS#7 -
PKCS#7 1.5 (RFC 2315) clearly distinguishes between a digestAlgorithm
and a digestEncryptionAlgorithm.
So if  the signatureAlgorithm is md5WithRSAEncryption
(1.2.840.113549.1.1.4), the digestAlgorithm is md5 (1.2.840.113549.2.5)
and the digestEncryptionAlgorithm is RSA (1.2.840.113549.1.1.1).
Or if the signatureAlgorithm is sha1WithRSAEncryption
(1.2.840.113549.1.1.5), the digestAlgorithm is sha1 (1.3.14.3.2.26)
and the digestEncryptionAlgorithm is again RSA (1.2.840.113549.1.1.1).
(The same for RipeMD160WithRsaEncryption (1.3.36.3.3.1.2))

Although 'only' RSA is mentioned in PKCS7 directly as a digest-
EncryptionAlgorithm, I assume that this rules also apply for other
'encryptionAlgorithm's.
All the PKCS#7 'samples' I've found strictly follows these rules, there
is always a digest and a digestEncryption algorithm.

- CMS (2630) -
CMS (RFC 2630) introduced the term signatureAlgorithm in the
SignerInfo structure, which has 'replaced' the digestEncryptionAlgorithm
of PKCS#7 while the digestAlgorithm field still remains.

If a signatureAlgorithm is used to create the signature whose cipher is
using the RSA algorithm, the 'old' RSA OID 1.2.840.113549.1.1.1 must be
used in the 'signatureAlgorithm' field. (12.2.2) The digestAlgorithm
field contains then the corresponding digest Oid, eg. SHA-1, MDx or
RipeMD160.
The usage of the signatureAlgorithmOids sha1WithRSAEncryption,
md5WithRSAEncryption or ripeMD160WithRsaEncryption is not allowed in
2630, the above mentioned schema must be used.
When using a signatureAlgorithm which has another cipher - like DSA or
ECDSA - the 'splitting' into a digest and a cipher algorithm is not
allowed, the signatureAlgorithmOid must be used. (e.g. sha1WithDSA
(1.2.840.10040.4.3)) and the digestAlgorithm field must contain the
digestAlgo 'included' in the signatureAlgo. Restrictions for the usage
of other signatureAlgoritms may be defined in other RFCs (like 3278).

- CMS (3369/70)
This successor of 2630 (more precise CMSALG) also allows the usage of
the signatureAlgorithmOID when a RSA cipher is used for the signature
process, which was/is not allowed in 2630. (sha1WithRSAEncryption,
md5WithRSAEncryption or ripeMD160WithRsaEncryption). For backward
compatibility, the 2630 schema (RSA) is also allowed here for the MD5
and SHA-1 digests.

Now my questions:

(1) Did I get the standard mentioned above right regarding the
     signatureAlgo/digestEncryptionAlgorithm?

(2) How should I handle a CMS (2630/3369) signature where the value of
     the digestAlgorithm does not match the 'included' digestAlgorithm in
     the signatureAlgorithm field. (e.g. having a RIPEMD160 digestAlgo
     OID at the digestInfo field and a Sha1WithDSA OID in the signature-
     algorithm field).

(3) When a component claims that it can produce valid RFC 2630
     signatures, is the usage of the 'old' RSA OID 1.2.840.113549.1.1.1
     the only exception from the rule? Is the usage of the 'other'
     RSA signature OIDs (sha1WithRSAEncryption) really forbidden in 2630?

(4) Having the following signatureAlgorithms, is the usage of these for
     PKCS#7/RFC 2630/RFC 3369 signatures allowed and correct?
     (having valid signatures according the corresponding standard)

---------------------------------------------------------------------------
SignatureAlgorithm      digestAlgo        (I)   digestEncrAlgo(PKCS#7)
                                           (II)  signatureAlgo (RFC 2630)
                                           (III) signatureAlgo (RFC 3369)
---------------------------------------------------------------------------

(A) sha1WithRSA            1.3.14.3.2.26  (I)      1.2.840.113549.1.1.1
    (1.2.840.113549.1.1.5)                 (II)     1.2.840.113549.1.1.1
                                           (IIIa)   1.2.840.113549.1.1.1
                                           (IIIb)   1.2.840.113549.1.1.5


(B) md5WithRSA           1.2.840.1x9.2.5  (I)      1.2.840.113549.1.1.1
    (1.2.840.113549.1.1.4)                 (II)     1.2.840.113549.1.1.1
                                           (IIIa)   1.2.840.113549.1.1.1
                                           (IIIb)   1.2.840.113549.1.1.4

(D) sha1WithDsa            1.3.14.3.2.26  (I)      1.2.840.10040.4.1
    (1.2.840.10040.4.3)                    (II)     1.2.840.10040.4.3
                                           (III)    1.2.840.10040.4.3

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

(5) Or is the signatureAlgorithm check performed this way (for
     2630/3369):
     If the signatureAlgo field contains a digestEncryptionOID, the
     signatureAlgo is the digestEncryptionOID plus the digestOID.
     If the signatureAlgo field contains a signatureAlgo, the
     signatureAlgo equals the found signatureAlgo. The included
     digestAlgo is not observed/must be the same as the one which
     is contained in the signatureAlgo/...?

Thanks in advance

Best Regards

Holger







Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1HIlqb04521 for ietf-smime-bks; Mon, 17 Feb 2003 10:47:52 -0800 (PST)
Received: from mail.epost.de (mail.epost.de [193.28.100.164] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1HIlod04516 for <[e-mail]>; Mon, 17 Feb 2003 10:47:50 -0800 (PST)
Received: from [129.70.36.57] (129.70.36.57) by mail.epost.de (6.7.015) (authenticated as [e-mail]) id 3E41A7C7001379CA; Mon, 17 Feb 2003 19:47:49 +0100
From: Marc Mutz <[e-mail]>
Organization: "Old Europe" - and proud
To: [e-mail]
Subject: [ot] Re: SMIME and disclaimers
Date: Mon, 17 Feb 2003 19:19:02 +0100
User-Agent: KMail/1.5.9
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Cc: [e-mail]
X-PGP-Key: 0xBDBFE838
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_peSU+5FCL1AaNkO"; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--Boundary-02=_peSU+5FCL1AaNkO
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Monday 17 February 2003 17:24, [e-mail] wrote:
<snip>
> The multipart nature of MIME suggests
> that it is at least plausible to place the disclaimer in its own MIME
> boundary such that it doesn't interfere with signed portions in the
> parts of the message that originate at the client.
<snip>

The application adding the disclaimer needs to be fully MIME-aware and=20
needs to be able to re-arrange the MIME body parts if necessary. Just=20
appending the disclaimer in plain text, US-ASCII form works only for=20
messages with text/plain top-level content-type and a charset that=20
contains US-ASCII as a subset (e.g. iso-8859-*, utf-8).

A more intelligent approach would be to find the last MIME boundary,=20
remove everything after and including the trailing double hyphen, and=20
add something like:
Content-Type: text/plain; charset=3Dus-ascii
Content-disposition: inline

<disclaimer goes here>
=2D-boundary--
but that fails for multiparts with a fixed number of required children,=20
e.g. multipart/signed, which needs to have exactly two children.

=46or coping with these messages, you have three options:
1. Lock down the signature (not the digital signature, but the message
   footer) to use for your users, if your mailer supports that (e.g.
   KMail does), so it includes the disclaimer and cannot be changed by
   the user.
2. Use an application that is dumb and just appends the disclaimer as
   text, like e.g. mailman does. Then you have to hope that all the
   recipients use MUAs that show the epilogue of mails if it looks
   interesting. Don't hold your breath...
3. Use an intelligent application to append the disclaimer, one that can
   re-arrange the MIME body structure to fold the current content into
   an additional multipart/mixed if needed to append the text/plain
   disclaimer and hope that recipient's clients can cope with deeply
   nested MIME body structures.

I guess your best bet is to look up the admin's handbook of your users'=20
MUAs and see if (1) is an option.

Marc

=2D-=20
"You're hackers, aren't you," the barman said, eyeing us. No one said
a thing. The darkness of the Eurotunnel rolled by. Apparently we'd
given ourselves away by talking too enthusiastically about IPv6. He
looked around conspiratorially, lowered his voice. "Can you get me
some credit card numbers?"
      -- James J. King "What's the shortest way to hack a Linux box?"
         Telepolis 2001/08/11 (#9293)

--Boundary-02=_peSU+5FCL1AaNkO
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA+USep3oWD+L2/6DgRAqJRAJ9vn2bT2PI2v3nWhas0LxpJBSz85gCgqnNR
odTFvFzt7pfOzQqMMFlRaBY=
=A3MN
-----END PGP SIGNATURE-----

--Boundary-02=_peSU+5FCL1AaNkO--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1HGOj529738 for ietf-smime-bks; Mon, 17 Feb 2003 08:24:45 -0800 (PST)
Received: from mail3.consignia.com (mail.royalmail.com [144.87.143.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1HGOid29734 for <[e-mail]>; Mon, 17 Feb 2003 08:24:44 -0800 (PST)
Received: from postoffice.co.uk (unknown [144.87.146.16]) by mail3.consignia.com (Postfix) with SMTP id CED4518FA5D for <[e-mail]>; Mon, 17 Feb 2003 16:25:07 +0000 (GMT)
Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 00256CD0.005A2DE1 ; Mon, 17 Feb 2003 16:24:59 +0000
X-Lotus-FromDomain: POSTOFFICE
From: [e-mail]
To: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 17 Feb 2003 16:24:33 +0000
Subject: SMIME and disclaimers
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

I don't imagine for a moment that we're the only ones looking at this issue.

Discounting whether disclaimers carry any worthwhile legal weight, technically
is it feasible to add a disclaimer to outgoing SMIME messages at the outgoing
server without breaking the signature ? The multipart nature of MIME suggests
that it is at least plausible to place the disclaimer in its own MIME boundary
such that it doesn't interfere with signed portions in the parts of the message
that originate at the client.

Opinions appreciated.

Chris

Royal Mail is a trading name of Royal Mail Group plc. Registered in England and
Wales.
Registered number 4138203. Registered office at 148 Old Street, LONDON EC1V 9HQ


This  email  and  any  attachments  are confidential and intended for the addressee
only.   If  you are not the named recipient, you must not use, disclose, reproduce,
copy  or  distribute the contents of this communication.  If you have received this
in error, please contact the sender and then delete this email from your system.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1FGHKI25831 for ietf-smime-bks; Sat, 15 Feb 2003 08:17:20 -0800 (PST)
Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1FGHId25827 for <[e-mail]>; Sat, 15 Feb 2003 08:17:19 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by maild.telia.com (8.12.5/8.12.5) with SMTP id h1FGHF2n012817 for <[e-mail]>; Sat, 15 Feb 2003 17:17:15 +0100 (CET)
X-Original-Recipient: <[e-mail]>
Message-ID: <00b601c2d50c$4d4d7180$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: e-Gov: Distributing confidential information
Date: Sat, 15 Feb 2003 17:07:13 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here are some thoughts regarding how e-governments (and companies)
could efficiently distribute confidential information to citizens 
(or employees).  Note: The following discussion only applies to
information from an (non-personal) authority to an individual.

Claim
-------
In spite of being the foundation for many PKI-based ID-programs,
I doubt that S/MIME will play any major role in e-government
systems as these typically are built as on-line (web-based) services.

The problem
--------------
Now, in case a government authority is to send you confidential
information, I believe they should not use encrypted mail as this
will most likely lead to huge support problems with key-
distribution, key-expiration etc.

A simple remedy
---------------------
e-Governments could preferably e-mail the recipient a web-link (or just
a notification) that he or she uses to fetch the confidential information with.
That is, after the recipient have authenticated to the on-line authority.
This scheme is also aligned with an "account-based" authority where
you may have tasks in various stages.

The "web-way" allowed on-line banks to address the ordinary consumer
and is proven to work on a major scale, while signed and encrypted
mail is after more than ten years, still very sparsely used.

My 2 cents.

Anders Rundgren
Consultant, PKI and secure e-business
+46 70 - 627 74 37





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1ELUes22662 for ietf-smime-bks; Fri, 14 Feb 2003 13:30:40 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1ELUcd22657 for <[e-mail]>; Fri, 14 Feb 2003 13:30:38 -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 QAA05443; Fri, 14 Feb 2003 16:26:49 -0500 (EST)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>, Internet Architecture Board <[e-mail]>, [e-mail]
From: The IESG <[e-mail]>
Subject: Protocol Action: CMS Symmetric Key Management and Distribution  to Proposed Standard
Date: Fri, 14 Feb 2003 16:26:49 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the Internet-Draft 'CMS Symmetric Key Management 
and Distribution' <draft-ietf-smime-symkeydist-09.txt> as a Proposed 
Standard. This document is the product of the S/MIME Mail Security 
Working Group. The IESG contact persons are Jeffrey Schiller and Steve 
Bellovin.
 
 
Technical Summary
 
This document extends the Cryptographic Message Syntax (CMS) to
support the use of symmetric (traditional) encryption in addition to
public key encryption. It describes an architecture that can be used
by Groups of entities (or Mailing Lists) to securely distribute a
Group Key which can be used to symmetrically encrypt CMS objects.

Working Group Summary

The working group had consensus on this document.

Protocol Quality

This document has been reviewed for the IESG by Jeff Schiller.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EJGWB16669 for ietf-smime-bks; Fri, 14 Feb 2003 11:16:32 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1EJGVd16665 for <[e-mail]>; Fri, 14 Feb 2003 11:16:31 -0800 (PST)
Received: (qmail 22980 invoked from network); 14 Feb 2003 19:16:25 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.175.84) by woodstock.binhost.com with SMTP; 14 Feb 2003 19:16:25 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Fri, 14 Feb 2003 14:16:31 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: draft-housley-cms-fw-wrap-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear S/MIME WG:

Since the vast majority of CMS experience exists in the S/MIME working 
group, I want to make people aware of this Internet-Draft.  I would greatly 
appreciate review and constructive comment.

Also, I would like to assign the needed OIDs from the S/MIME working group 
arc.  Does anyone see any reason for them to be assigned elsewhere?

Russ



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EIp7U15702 for ietf-smime-bks; Fri, 14 Feb 2003 10:51:07 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1EIp6d15698 for <[e-mail]>; Fri, 14 Feb 2003 10:51:06 -0800 (PST)
Received: (qmail 21647 invoked from network); 14 Feb 2003 18:50:59 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.180.81) by woodstock.binhost.com with SMTP; 14 Feb 2003 18:50:59 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Fri, 14 Feb 2003 13:50:51 -0500
To: Petra Barzin <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: mistake in RFC 3126
Cc: [e-mail], Stephan Klein <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This definitely looks like an error to me.

Russ


At 10:27 AM 2/13/2003 +0100, Petra Barzin wrote:
>Hello,
>
>I think there is a mistake in RFC 3126 - Electronic Signature
>Formats for long term electronic signatures. The definition of the
>RevocationValues attribute is as follows:
>
>   RevocationValues ::=  SEQUENCE {
>       crlVals           [0] SEQUENCE OF CertificateList     OPTIONAL,
>       ocspVals          [1] SEQUENCE OF BasicOCSPResponse   OPTIONAL,
>       otherRevVals      [2] OtherRevVals
>    }
>
>Shouldn't the other revocation values be optional as well?
>Did I miss something or am I right?
>
>Best regards - Petra Barzin
>
>
>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1DNGJc29597 for ietf-smime-bks; Thu, 13 Feb 2003 15:16:19 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1DNGId29593 for <[e-mail]>; Thu, 13 Feb 2003 15:16:18 -0800 (PST)
Received: (qmail 13145 invoked from network); 13 Feb 2003 23:16:12 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.161.174) by woodstock.binhost.com with SMTP; 13 Feb 2003 23:16:12 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 13 Feb 2003 18:16:11 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Overhead Projectors at the IETF meeting in San Francisco
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear S/MIME participants:

Starting with the IETF meeting in San Francisco, overhead projectors will 
not be provided in the meeting rooms unless specifically requested.  Data 
projectors will be in all working group and BOF meeting rooms.

If you feel there is a need for an overhead projector in our session, 
please send me a note immediately.

Thanks,
   Russ



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1DI1ta18953 for ietf-smime-bks; Thu, 13 Feb 2003 10:01:55 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DI1sd18948 for <[e-mail]>; Thu, 13 Feb 2003 10:01:54 -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 MAA20172; Thu, 13 Feb 2003 12:58:11 -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-hmac-key-wrap-01.txt
Date: Thu, 13 Feb 2003 12:58:11 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Wrapping an HMAC key with a Triple-DES Key or an AES Key
	Author(s)	: J. Schaad, R. Housley
	Filename	: draft-ietf-smime-hmac-key-wrap-01.txt
	Pages		: 8
	Date		: 2003-2-12
	
The key wrap algorithms defined in [3DES-WRAP] and [AES-WRAP] cover 
the of wrapping a Triple-DES key with another Triple-DES key and 
wrapping an AES key with another AES key, respectively.  This 
document specifies two similar mechanisms.  One specifies the 
mechanism for wrapping an HMAC key with a Triple-DES key, and the 
other specifies the mechanism for wrapping an HMAC key with an AES 
key.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-hmac-key-wrap-01.txt".

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-hmac-key-wrap-01.txt

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1D9PSq17053 for ietf-smime-bks; Thu, 13 Feb 2003 01:25:28 -0800 (PST)
Received: from linux.secude.com (linux.secude.com [141.12.207.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1D9OCd17015 for <[e-mail]>; Thu, 13 Feb 2003 01:24:12 -0800 (PST)
Received: from remus.intranet.secude.com (remus.intranet.secude.com [192.168.2.2]) by linux.secude.com (Postfix) with ESMTP id 42EA4B564; Thu, 13 Feb 2003 10:24:11 +0100 (CET)
Received: from secude.com (pc-yameogo.intranet.secude.com [192.168.3.51]) by remus.intranet.secude.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id Z3LLM93X; Thu, 13 Feb 2003 10:26:51 +0100
Message-ID: <[e-mail]>
Date: Thu, 13 Feb 2003 10:27:18 +0100
From: Petra Barzin <[e-mail]>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Cc: [e-mail], Stephan Klein <[e-mail]>, [e-mail]
Subject: mistake in RFC 3126
Content-Type: multipart/mixed; boundary="------------ED2A3168A497312B1CC7A265"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------ED2A3168A497312B1CC7A265
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello,

I think there is a mistake in RFC 3126 - Electronic Signature
Formats for long term electronic signatures. The definition of the
RevocationValues attribute is as follows:

  RevocationValues ::=  SEQUENCE {
      crlVals           [0] SEQUENCE OF CertificateList     OPTIONAL,
      ocspVals          [1] SEQUENCE OF BasicOCSPResponse   OPTIONAL,
      otherRevVals      [2] OtherRevVals
   }

Shouldn't the other revocation values be optional as well?
Did I miss something or am I right?

Best regards - Petra Barzin




--------------ED2A3168A497312B1CC7A265
Content-Type: text/x-vcard; charset=us-ascii;
 name="barzin.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Petra Barzin
Content-Disposition: attachment;
 filename="barzin.vcf"

begin:vcard 
n:Barzin;Petra
tel;fax:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.secude.com
org:SECUDE GmbH
adr:;;Dolivostr. 11;Darmstadt;;64293 ;Deutschland
version:2.1
email;internet:[e-mail]
fn:Petra Barzin
end:vcard

--------------ED2A3168A497312B1CC7A265--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1C3YtR25931 for ietf-smime-bks; Tue, 11 Feb 2003 19:34:55 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1C3YCd25902 for <[e-mail]>; Tue, 11 Feb 2003 19:34:54 -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 WAA26725; Tue, 11 Feb 2003 22:30:32 -0500 (EST)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: [e-mail]
From: The IESG <[e-mail]>
SUBJECT: Last Call: Use of the AES Encryption Algorithm in CMS to  Proposed Standard
Reply-to: [e-mail]
Date: Tue, 11 Feb 2003 22:30:32 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has received a request from the S/MIME Mail Security Working 
Group to consider Use of the AES Encryption Algorithm in CMS 
<draft-ietf-smime-aes-alg-06.txt> as a Proposed Standard.  

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

Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-aes-alg-06.txt





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h154xAf08334 for ietf-smime-bks; Tue, 4 Feb 2003 20:59:10 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h154x9d08329 for <[e-mail]>; Tue, 4 Feb 2003 20:59:09 -0800 (PST)
Received: (qmail 18403 invoked from network); 5 Feb 2003 04:59:08 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (198.202.64.143) by woodstock.binhost.com with SMTP; 5 Feb 2003 04:59:08 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 04 Feb 2003 16:25:20 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: WG Last Call: draft-ietf-smime-rfc2633bis-03.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have a few comments on draft-ietf-smime-rfc2633bis-03.txt.   My comments 
are divided into technical and editorial.  In my opinion, the technical 
comments ought to be resolved before the document is forwarded to the IESG.


TECHNICAL COMMENTS

Section 1.1, 4th paragraph.  Change "... an S/MIME agent has to follow ..." 
to "... an S/MIME agent MUST follow ... ."  I realize that this MUST 
statement will appear before section 1.2, but I do not see any other MUST 
statements that capture this point.  Alternatively, insert an appropriate 
MUST statement elsewhere in the document.

Section 2.4.  CompressedData needs to be added to the list of content types 
that are supported.  Also, section 2.4.4 should be added to discuss the 
content type.

Section 2.5, 2nd paragraph.  CMS requires the inclusion of the contentType 
and messageDigest signed attributes if any other signed attributes are 
present.  We should include these in the bulleted list.

Section 2.5, last paragraph.  How do mail list agents fit into this 
requirement to "display those attributes to the user?"  Such devices 
certainly do not have a user interface, but they must include 
mlExpansionHistory.

Section 2.5.2, 6th paragraph.  Please reword: "The OIDs used with S/MIME 
are assigned in several different RFCs; however, all OIDs associated with 
the MUST and SHOULD implement algorithms are included in Appendix A of this 
document."

Section 3.4.3.2, micalg table.  Please add SHA-256, SHA-384, and SHA-512 to 
avoid the need for future updates.  A reference to FIPS 180-2 will be needed.

Section 3.8, last paragraph.  Please reword as follows: "S/MIME v2 
[SMIMEV2] specified a method for "registering" public keys with certificate 
authorities using an application/pkcs10 body part.  Since that time, the 
IETF PKIX Working Group has developed other methods for requesting 
certificates.  However, S/MIME v3.1 does not require a particular 
certificate request mechanism."


EDITORIAL COMMENTS

General.  Please change "CMS objects" to "CMS content types"  throughout 
the specification.

Section 1.1, 2nd paragraph.  Remove the extra space from 
"application/pkcs7- mime."

Section 1.3.  Please add references for X.208, X.209, and X.509, including 
the date of the version that is being referenced.  I suspect that the same 
ones that are used in [CMS] should be referenced.

Section 2.5.  Please reword the 3rd paragraph, as follows: "Further, 
receiving agents SHOULD be able to handle zero or one instance in the 
signingCertificate signed attribute, as defined in section 5 of [ESS]."

Section 2.5.2, 3rd paragraph.  Change "OIDs" to "object identifiers (OIDs)."

Section 2.6.  This paragraph should talk about S/MIME v3.1 as well as 
S/MIME v3.

Section 2.7.1.2.  Change the first part of the first sentence to: "If the 
following three conditions are met:"

Section 2.7.1.3.  Change the first part of the first sentence to: "If the 
following two conditions are met:"

Section 3, 1st paragraph.  Please change "CMS objects" to "CMS content 
types."  This is used several places.

Section 3.1, 1st paragraph.  Add a forward pointer to the processing that 
is used when RFC 822 headers need protection.

Section 3.1.3, 1st paragraph.  The word "EVER" does not have a reserved 
meaning in RFC 2119.  Please change it to lower case.

Section 3.2, 1st paragraph.  Remove the extra space from 
"application/pkcs7- mime type."

Section 3.2.2, 1st paragraph.  Remove the extra space from "smime- types."

Section 3.2,2, 3rd paragraph.  Remove the extra space from "encrypted- *."

Section 3.6, 1st paragraph.  Please reword as: "The signed-only, 
encrypted-only, and compressed-only MIME formats can be nested. This works 
because these formats are all MIME entities that encapsulate other MIME 
entities."

Section 3.9, 1st paragraph, last sentence.  Please reword as follows: "A 
message is considered an S/MIME message if it matches any of the criteria 
listed below."


Russ



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h14FFLb12761 for ietf-smime-bks; Tue, 4 Feb 2003 07:15:21 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h14FFKd12757 for <[e-mail]>; Tue, 4 Feb 2003 07:15:20 -0800 (PST)
Received: (qmail 27578 invoked from network); 4 Feb 2003 15:15:07 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.39.35) by woodstock.binhost.com with SMTP; 4 Feb 2003 15:15:07 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 04 Feb 2003 10:15:09 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: WG Last Call: draft-ietf-smime-rfc2633bis-03.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear S/MIME WG:

This message announces Working Group Last Call for the update to the MSG 
specification.

	Title		: S/MIME Version 3.1 Message Specification
	Author(s)	: Blake Ramsdell
	Filename	: draft-ietf-smime-rfc2633bis-03.txt
	Date		: January 16, 2003
	
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2633bis-03.txt

The intent is to publish the pdate to the MSG specification as a Standards 
Track RFC, superseding RFC 2633.

Please review this draft and post any comments to the [e-mail] 
mail list by Monday, 17 February 2003.  Unless traffic on the mail list 
indicates otherwise, I will send these to the IESG shortly after WG Last 
Call closes.

Russ



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h11IkEW10734 for ietf-smime-bks; Sat, 1 Feb 2003 10:46:14 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h11IkDo10727 for <[e-mail]>; Sat, 1 Feb 2003 10:46:13 -0800 (PST)
Received: (qmail 16284 invoked from network); 1 Feb 2003 18:46:11 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.162.139) by woodstock.binhost.com with SMTP; 1 Feb 2003 18:46:11 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Sat, 01 Feb 2003 13:46:11 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: S/MIME WG Agenda for 56th IETF 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The 56th IETF will be held in San Francisco, CA on 16-21 March 2003.  I 
have asked for a one-hour meeting slot for the S/MIME WG.  Please send me 
agenda topics.

Russ