WG Last Call: draft-ietf-smime-camellia-02.txt

["Blake Ramsdell" <[e-mail]>]

Dear S/MIME WG:

This message announces Working Group Last Call for the use of the
Camellia Encryption Algorithm in CMS.

	Title		: Use of the Camellia Encryption Algorithm in
CMS
	Author(s)	: S. Moriai, A. Kato
	Filename	: draft-ietf-smime-camellia-02.txt
	Pages		: 11
	Date		: 2003-3-27

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

The intent is to publish this document as a Standards Track RFC.

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

</EndOfBoilerplate>

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




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h312GBJM026543 for <[e-mail]>; Mon, 31 Mar 2003 18:16:11 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h312GBCE026542 for ietf-smime-bks; Mon, 31 Mar 2003 18:16:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.11.6) with ESMTP id h312GAJM026538 for <[e-mail]>; Mon, 31 Mar 2003 18:16:10 -0800 (PST)
Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Mon, 31 Mar 2003 18:16:09 -0800
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>
Subject: WG Last Call: draft-ietf-smime-camellia-02.txt
Date: Mon, 31 Mar 2003 18:16:08 -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
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 use of the
Camellia Encryption Algorithm in CMS.

	Title		: Use of the Camellia Encryption Algorithm in
CMS
	Author(s)	: S. Moriai, A. Kato
	Filename	: draft-ietf-smime-camellia-02.txt
	Pages		: 11
	Date		: 2003-3-27

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

The intent is to publish this document as a Standards Track RFC.

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

</EndOfBoilerplate>

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



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2SCP3P16943 for ietf-smime-bks; Fri, 28 Mar 2003 04:25:03 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2SCP2g16939 for <[e-mail]>; Fri, 28 Mar 2003 04:25:02 -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 HAA25688; Fri, 28 Mar 2003 07:22:40 -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-camellia-02.txt
Date: Fri, 28 Mar 2003 07:22:40 -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 Camellia Encryption Algorithm in CMS
	Author(s)	: S. Moriai, A. Kato
	Filename	: draft-ietf-smime-camellia-02.txt
	Pages		: 11
	Date		: 2003-3-27
	
This document specifies how to incorporate the Camellia encryption
algorithm into the S/MIME Cryptographic Message Syntax (CMS) as an
additional algorithm for symmetric encryption.  The relevant object
identifiers (OIDs) and processing steps are provided so that
Camellia may be used in the CMS specification (RFC 3369, RFC 3370)
for content and key encryption.

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2RKUFH11877 for ietf-smime-bks; Thu, 27 Mar 2003 12:30:15 -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.6) with ESMTP id h2RKUEg11873 for <[e-mail]>; Thu, 27 Mar 2003 12:30:14 -0800 (PST)
Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Thu, 27 Mar 2003 12:30:11 -0800
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>, "'Ietf-Smime'" <[e-mail]>
Subject: RE: Draft Minutes
Date: Thu, 27 Mar 2003 12:30:10 -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: <003a01c2f357$aadeaee0$[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: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Jim Schaad
> Sent: Tuesday, March 25, 2003 9:22 PM
> To: Ietf-Smime
> Subject: Draft Minutes
> 
> Here are the minutes for the San Fransico meeting.

We'd like to get any comments by tomorrow (Friday) so we can get these
finalized.

Blake



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2QK3QT05669 for ietf-smime-bks; Wed, 26 Mar 2003 12:03:26 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.6) with SMTP id h2QK3Pg05662 for <[e-mail]>; Wed, 26 Mar 2003 12:03:25 -0800 (PST)
Received: (qmail 22842 invoked from network); 26 Mar 2003 20:02:44 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.165.83) by woodstock.binhost.com with SMTP; 26 Mar 2003 20:02:44 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 26 Mar 2003 15:03:00 -0500
To: "Pandey, Arun" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Queries on Message/rfc822, Compressed-Data.
Cc: [e-mail]
In-Reply-To: <[e-mail]. com>
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-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<html>
<body>
These are both discussed in the most recent MSG draft.<br>
Please see draft-ietf-smime-rfc2633bis-03.txt.<br><br>
Russ<br><br>
At 03:40 PM 3/26/2003 +0530, Pandey, Arun wrote:<br><br>
<blockquote type=cite class=cite cite><font size=2>Hi,</font> <br><br>
<font size=2>I had the following 2 queries. Would appreciate a response
on these if possible:</font> <br><br>
<font size=2>1. Going&nbsp; through the S/MIME mail archive I find a
discussion on the use of message types like </font><br>
<font size=2>&nbsp;&nbsp;&nbsp; message/rfc822, message/partial etc. that
could be used to wrap a protected message (MIME </font><br>
<font size=2>&nbsp;&nbsp;&nbsp; content + RFC822 Headers). Also as per
MOM of the 54th IETF meeting it seems that </font><br>
<font size=2>&nbsp;&nbsp;&nbsp; message/rfc822 message type has been
finalized for this purpose.</font> <br><br>
<font size=2>&nbsp;&nbsp;&nbsp; My question is how should one distinguish
such a message ( A protected message wrapped </font><br>
<font size=2>&nbsp;&nbsp;&nbsp; in message/rfc822) from a forwarded
message which also has a message type of </font><br>
<font size=2>&nbsp;&nbsp;&nbsp; message/rfc822 and can also contain a non
protected message? Is an example message of </font><br>
<font size=2>&nbsp;&nbsp;&nbsp; type message/rfc822 containing a
protected message available for reference?</font> <br><br>
<font size=2>2. The latest draft 'S/MIME Version 3.1 Message
Specification' (draft-ietf-smime-rfc2633bis-03.txt)</font> <br>
<font size=2>&nbsp;&nbsp;&nbsp; mentions a new S/MIME type
&quot;compressed-data&quot;. However for this new S/MIME type no
</font><br>
<font size=2>&nbsp;&nbsp;&nbsp; corresponding EIT has been defined in the
S/MIME TRANSPORT draft. Where would one be </font><br>
<font size=2>&nbsp;&nbsp;&nbsp; able to find the corresponding EIT for
the same?</font> <br><br>
<font size=2>Best Regards</font> <br>
<font size=2>Arun Pandey</font> <br>
</blockquote></body>
</html>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2QFk9U21487 for ietf-smime-bks; Wed, 26 Mar 2003 07:46:09 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.6) with SMTP id h2QFk8g21481 for <[e-mail]>; Wed, 26 Mar 2003 07:46:08 -0800 (PST)
Received: (qmail 9545 invoked from network); 26 Mar 2003 15:45:49 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.32.250) by woodstock.binhost.com with SMTP; 26 Mar 2003 15:45:49 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 26 Mar 2003 10:44:03 -0500
To: <[e-mail]>, "Ietf-Smime" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Draft Minutes
In-Reply-To: <003a01c2f357$aadeaee0$[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>

Jim:

Nice job.  One comment.

s/V3 Attribute Certificate Profile/V2 Attribute Certificate Profile/

Russ



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2QAFvd24072 for ietf-smime-bks; Wed, 26 Mar 2003 02:15:57 -0800 (PST)
Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2QAFug24067 for <[e-mail]>; Wed, 26 Mar 2003 02:15:56 -0800 (PST)
Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 4E739835B for <[e-mail]>; Wed, 26 Mar 2003 04:15:41 -0600 (CST)
Received: from diexch01.xko.dec.com (diexch01.xko.dec.com [16.138.244.57]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id A2FCF1719 for <[e-mail]>; Wed, 26 Mar 2003 04:15:39 -0600 (CST)
Received: by diexch01.xko.dec.com with Internet Mail Service (5.5.2650.21) id <G59FKNCB>; Wed, 26 Mar 2003 15:40:53 +0530
Message-ID: <[e-mail]>
From: "Pandey, Arun" <[e-mail]>
To: [e-mail]
Subject: Queries on Message/rfc822, Compressed-Data.
Date: Wed, 26 Mar 2003 15:40:52 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F37F.FBC23480"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

------_=_NextPart_001_01C2F37F.FBC23480
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,

I had the following 2 queries. Would appreciate a response on these if
possible:

1. Going  through the S/MIME mail archive I find a discussion on the use of
message types like 
    message/rfc822, message/partial etc. that could be used to wrap a
protected message (MIME 
    content + RFC822 Headers). Also as per MOM of the 54th IETF meeting it
seems that 
    message/rfc822 message type has been finalized for this purpose.

    My question is how should one distinguish such a message ( A protected
message wrapped 
    in message/rfc822) from a forwarded message which also has a message
type of 
    message/rfc822 and can also contain a non protected message? Is an
example message of 
    type message/rfc822 containing a protected message available for
reference?

2. The latest draft 'S/MIME Version 3.1 Message Specification'
(draft-ietf-smime-rfc2633bis-03.txt)
    mentions a new S/MIME type "compressed-data". However for this new
S/MIME type no 
    corresponding EIT has been defined in the S/MIME TRANSPORT draft. Where
would one be 
    able to find the corresponding EIT for the same?

Best Regards
Arun Pandey



------_=_NextPart_001_01C2F37F.FBC23480
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>Queries on Message/rfc822, Compressed-Data.</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I had the following 2 queries. Would =
appreciate a response on these if possible:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">1. Going&nbsp; through the S/MIME mail =
archive I find a discussion on the use of message types like </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; message/rfc822, =
message/partial etc. that could be used to wrap a protected message =
(MIME </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; content + RFC822 =
Headers). Also as per MOM of the 54th IETF meeting it seems that =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; message/rfc822 =
message type has been finalized for this purpose.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; My question is how =
should one distinguish such a message ( A protected message wrapped =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; in message/rfc822) =
from a forwarded message which also has a message type of </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; message/rfc822 and =
can also contain a non protected message? Is an example message of =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; type =
message/rfc822 containing a protected message available for =
reference?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">2. The latest draft 'S/MIME Version =
3.1 Message Specification' (draft-ietf-smime-rfc2633bis-03.txt)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; mentions a new =
S/MIME type &quot;compressed-data&quot;. However for this new S/MIME =
type no </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; corresponding EIT =
has been defined in the S/MIME TRANSPORT draft. Where would one be =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; able to find the =
corresponding EIT for the same?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Best Regards</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Arun Pandey</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C2F37F.FBC23480--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2Q5MJ926869 for ietf-smime-bks; Tue, 25 Mar 2003 21:22:19 -0800 (PST)
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2Q5MDg26865 for <[e-mail]>; Tue, 25 Mar 2003 21:22:13 -0800 (PST)
Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp4.pacifier.net (Postfix) with ESMTP id C0C536A503 for <[e-mail]>; Tue, 25 Mar 2003 21:04:13 -0800 (PST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "Ietf-Smime" <[e-mail]>
Subject: Draft Minutes
Date: Tue, 25 Mar 2003 21:22:16 -0800
Message-ID: <003a01c2f357$aadeaee0$[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.2600.0000
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>

Here are the minutes for the San Fransico meeting.

Minutes for the S/MIME Meeting
IETF 56
March 18, 2003

Agenda:  Russ Housley covered the agenda for the meeting.  No changes
were made.

Working Group Status:  Russ Housley covered the status of the active
documents in the working group.  The documents that have changed status
since the last meeting are:

Published as an RFC:
- RFC 3394    Advanced Encryption Standard (AES) Key Wrap Algorithm.

RFC Editors Queue:
- symkeydist   CMS Symmetric Key Management and Distribution

With the IESG:
- Use of the RSAES-OAEP Transport Algorithm in CMS
- Transporting S/MIME Objects in X.400
- Securing X.400 Content with S/MIME
- Wrapping an HMAC key with a Triple-DES Key or an AES Key
- Use of the AES Encryption Algorithm in CMS.

Progression to Draft Standard:  Need to have two interoperable
implementations (see report below) and all referenced documents advance
to Draft Standard.  For CMS to advance this means RFC 3280 (Certificate
Profile) and RFC 3281 (V3 Attribute Certificate Profile) need to advance
first.

Russ then resigned as the chair of the S/MIME working group due to his
promotion to the position of Security Area Director on the IESG.  The
new co-chairs of the working group are Blake Ramsdell
([e-mail]) and Sean Turner ([e-mail]).  Blake
and Sean chaired the balance of the meeting.

Message Update and Certificate Update Drafts:  Blake Ramsdell gave a
presentation on the progress of these two documents.  The message draft
has had a number of small changes between the -02 and -03 drafts.  The
document was put into working group last call after the last meeting.
The comments on the list have not yet been incorporated into a published
draft but that should be done soon.  The certificate draft has had some
minor changes in the extended key usage description and should go into
working group last call in the near future.

Examples Draft:  Paul Hoffman said that there have been some new
examples submitted for the draft; however these contained some personal
email addresses so Paul has asked that they be regenerated.  Areas of
the document that do not currently have examples have been removed.
When the new examples are placed in the document it should be ready for
working group last call.

CMS Interoperability Status:  Jim Schaad stated that advancement has
been made since the last meeting for CMS interoperability.  Four items
need to be tested, but implementers have been found for SignedData.  The
document describing the results of the interoperability testing has been
started.  This document should be ready for publishing before the next
meeting.  During the process of developing the matrix an error was
discovered in the CMS ASN.1 module, an update has been submitted to the
RFC Editor to supply the missing OIDs from the module.  Eventually, an
update to the RFC will be needed, perhaps when the document progresses
to Draft Standard.

RSA PSS: Jim Schaad presented two issues with the RSA PSS draft. The
first dealt with whether the key identifier and signature identifier
should use the existing OIDs or whether new ones should be assigned. The
second dealt with PSS parameter comparisons. Paul Hoffman raised a
concert about the reason for having the PSS draft, a second signature
algorithm (DSS) is already documented by the working group.  Russ
Housley and others indicated that having a backup was the main reason,
and this permitted a backup within the RSA family of algorithms.  Blake
Ramsdell then raised a concern over whether the working group is going
to become a location for anybody to create a document for their favorite
algorithm.  Russ Housley indicated that this was within the scope of the
group's charter. If interested in the RSA PSS outcome working group
members are directed to comment on the PKIX mailing list
([e-mail]).

SIP and SIPPING:  Rohan Mahy, one of the co-chairs for the SIP working
group, gave a presentation on how SIP/SIPPING are in the process of
using S/MIME and CMS in the SIP protocol for providing origin
authentication, integrity and confidentiality security services. These
were added in a hurry to RFC 3261 just before adoption.  Rohan was
asking to get some help both for providing implementation assistance and
advise on what should be specified in future documents from the groups.

Camellia Draft: KATO Akihiro gave the presentation on the draft for
Camellia to be used as a content encryption algorithm with CMS.  Draft
-01 contains two additional sections, one for S/MIME Capabilities and
one for Key Wrap algorithm details.  Some comments have been made on the
-01 draft, after these are address the document should be ready for
working group last call.  Information on Camellia can be obtained at
http//info.isl.ntt.co.jp/camellia.

ESS Document Updates:  Jim Schaad gave a brief description of a problem
that has been identified with the ML Expansion History update in the ESS
document.  The problem is that this signed attribute currently addresses
two different problems, the detection of loops during ML expansion and
changing receipt generation behavior.  This means that a work flow
application cannot easily change the receipt behavior without appearing
to be an MLA.  The proposal is to split these two different requirements
into separate signed attributes.  An MLA would make use of both new
attributes, but the work flow application would only make use of one of
them.  An update the ESS document (RFC 2634) is needed.

Summary:

- CERTbis, MSGbis, Examples, and Camellia drafts will undergo working
group last call as soon as next versions are published.

- ESS draft to be updated to address workflow issue.

- SIP/SIPPING issues to be addressed by S/MIME mailing list.

- RSA PSS signatures will be adopted as described in PKIX.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2OCS8H29808 for ietf-smime-bks; Mon, 24 Mar 2003 04:28:08 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2OCS7g29803 for <[e-mail]>; Mon, 24 Mar 2003 04:28:07 -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 HAA12246; Mon, 24 Mar 2003 07:25:48 -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-02.txt
Date: Mon, 24 Mar 2003 07:25:48 -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-02.txt
	Pages		: 8
	Date		: 2003-3-21
	
This document defines two methods for wrapping an HMAC (Hashed 
Message Authentication Code) key.  The first method defined uses a 
Triple DES (Data Encryption Standard) key to encrypt the HMAC key.  
The second method defined uses an AES (Advanced Encryption Standard) 
key to encrypt the HMAC key.  One place that such an algorithm is 
used is for the Authenticated Data type in CMS (Cryptographic 
Message Syntax).

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2ICb6p04122 for ietf-smime-bks; Tue, 18 Mar 2003 04:37:06 -0800 (PST)
Received: from smtp23.kolumbus.fi (smtp23.kolumbus.fi [193.229.0.81]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ICGbg01902; Tue, 18 Mar 2003 04:16:38 -0800 (PST)
Received: from dom1-cn2-hki.dom1.epnet (dom1-cn2-hki.dom1.epnet [172.21.176.74]) by smtp23.kolumbus.fi (8.12.8/8.12.4) with ESMTP id h2ICGU8D013502; Tue, 18 Mar 2003 14:16:30 +0200 (EET)
Received: from dom1-mb1-hki.dom1.epnet ([172.21.176.65]) by dom1-cn2-hki.dom1.epnet with Microsoft SMTPSVC(5.0.2195.5329); Tue, 18 Mar 2003 14:16:28 +0200
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: RE: Recommendation on subject matching rules needed..
Date: Tue, 18 Mar 2003 14:16:28 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Recommendation on subject matching rules needed..
Thread-Index: AcLsnzuZOwj2dhVaT1aAMDWXfBe6nAApbtCw
From: "Vainikainen Saku EINT" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 18 Mar 2003 12:16:28.0462 (UTC) FILETIME=[33F074E0:01C2ED48]
X-MailScanner: Found to be clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2ICGdg01905
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>

> >Sounds good, but I suppose we still need to select the keys somehow 
> >(using the certs) through the CryptoAPI CSP and RSA CrypTokI 
> interface, 
> >so that the applications are satisfied.
> 
> It looks like you've been painted into a corner by the 
> selection of software you have to use.  The solution using 
> other software is fairly simple, but if you're stuck with 
> using CryptoAPI and have various other constraints I don't 
> really know what you could do, sorry.  I guess saying "Don't 
> do that then" isn't much help :-).

Yep. Although I don't know of any other non-proprietary
crypto-interfaces that have "widespread" application support so I don't
really see another way around the problem other than put pressure on the
application vendors.

And putting this pressure would be greatly helped by you guys at IETF
PKIX & SMIME if you would draft up a paper about the subject. It could
be part of SMIME specs but I would like to see it a part of PKIX specs,
since the same issue is present when building certification paths during
certificate verification process, as well as when making the call wether
to trust the presented CA certificate or not..

Saku.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2HDbOw02878 for ietf-smime-bks; Mon, 17 Mar 2003 05:37:24 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz ([130.216.35.151]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2HDW0g02126; Mon, 17 Mar 2003 05:32:00 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.8/8.12.8) with ESMTP id h2HDPQVV026520; Tue, 18 Mar 2003 01:25:26 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h2HDPQi17223; Tue, 18 Mar 2003 01:25:26 +1200
Date: Tue, 18 Mar 2003 01:25:26 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Recommendation on subject matching rules needed..
Cc: [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>

"Vainikainen Saku EINT" <[e-mail]> writes:

>Sounds good, but I suppose we still need to select the keys somehow
>(using the certs) through the CryptoAPI CSP and RSA CrypTokI interface,
>so that the applications are satisfied.

It looks like you've been painted into a corner by the selection of software
you have to use.  The solution using other software is fairly simple, but
if you're stuck with using CryptoAPI and have various other constraints I
don't really know what you could do, sorry.  I guess saying "Don't do that
then" isn't much help :-).

Peter.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BJt9603272 for ietf-smime-bks; Tue, 11 Mar 2003 11:55:09 -0800 (PST)
Received: from smtp23.kolumbus.fi (smtp23.kolumbus.fi [193.229.0.81]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BJo5302989; Tue, 11 Mar 2003 11:50:05 -0800 (PST)
Received: from dom1-cn1-hki.dom1.epnet (dom1-cn1-hki.dom1.epnet [172.21.176.70]) by smtp23.kolumbus.fi (8.12.8/8.12.4) with ESMTP id h2BJo09b016791; Tue, 11 Mar 2003 21:50:00 +0200 (EET)
Received: from dom1-mb1-hki.dom1.epnet ([172.21.176.65]) by dom1-cn1-hki.dom1.epnet with Microsoft SMTPSVC(5.0.2195.5329); Tue, 11 Mar 2003 21:49:59 +0200
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: RE: Recommendation on subject matching rules needed..
Date: Tue, 11 Mar 2003 21:49:59 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Recommendation on subject matching rules needed..
Thread-Index: AcLn9wuEAL4OU7sYQx2FtTZ0MwCK1gABB7WA
From: "Vainikainen Saku EINT" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 11 Mar 2003 19:49:59.0705 (UTC) FILETIME=[66366090:01C2E807]
X-MailScanner: Found to be clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2BJo6302992
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>

> But why do you need to store all this cruft?  If it's a 
> legacy/superseded decryption key, all you need is the 
> private-key components for decryption (usually stored in a 
> highly compact card-specific format) and the 
> issuerAndSerialNumberHash so you can locate it (in fact for 
> any decryption key, even a currently active one, you don't 
> actually need to store the cert). The overhead for the non- 
> private-key components would probably be 50-100 bytes, 
> depending on how much other stuff your PKCS #15 
> implementation stores alongside it.  So your card contains 
> the current decryption key and its cert, and one (or possibly 
> more, although you probably need to ask why the user is 
> losing that many keys) decryption keys and the index info 
> needed to find them. The indexing overhead for half a dozen 
> decryption keys is going to be less than that for a single 
> certificate.

Sounds good, but I suppose we still need to select the keys somehow
(using the certs) through the CryptoAPI CSP and RSA CrypTokI interface,
so that the applications are satisfied.

I assume PKCS#11 is not that a big problem in terms of key
types/parameters since it recognises keys with key usage bits and relays
key parameters from the PKCS#15 structure, but if I don't remember
incorrectly, MSoft CSP is a problem since it only recognises two types
of keys (AT_KEYEXCHANGE and AT_SIGNATURE) and thus it has no clue about
the key usage bits. And both interfaces can do the mapping between
public keys and corresponding private keys.

But I don't recall if there is an attribute that could store
issuerAndSerialNumber in either PKCS#11 or CSP specifications. So could
we really relay this info to apps ?

This implies more or less that the applications have to locate the
decryption key (private key) based on certificate comparison (or public
key comparison) to locate the related public key. And when using
certificates, comparing issuerAndSerialNumber is not good enough since
it only recognises the certificate, not the entity nor the key pair
described in the cert.

If we compare the subject and issuer data (key ids, subject and issuer
names, subject and issuer unique ids), we recognise the entity
identified by the certificate, not the certificate itself - and in my
opinion, this is what we are after when we are using certificates. Eg.
in S/MIME, we figure out if the encrypted mail is really intended to the
entity trying to open it rather than figuring out if the certificate
linked to the recipient's private key he/she is trying to use in
decrypting the mail, is the same certificate that was used to encrypt
the mail.

Saku.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BJSnR01024 for ietf-smime-bks; Tue, 11 Mar 2003 11:28:49 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.6) with SMTP id h2BJSm301018 for <[e-mail]>; Tue, 11 Mar 2003 11:28:48 -0800 (PST)
Received: (qmail 20724 invoked from network); 11 Mar 2003 19:28:31 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (12.148.142.25) by woodstock.binhost.com with SMTP; 11 Mar 2003 19:28:31 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 11 Mar 2003 14:25:24 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Anyone want to be the S/MIME Jabber Scribe?
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:

At the last meeting, Al Arsenault agreed to be the Jabber  scribe for the 
S/MIME session.  Al cannot make the meeting in San Francisco.  If we are 
going to participate in this activity, we need a scribe.  Any volunteers?

Russ

==================

	Remote Access for the 56th IETF meeting in San Francisco:
			     Text Conferencing

At each IETF meeting, two of the working group meeting rooms are equipped
for video multicast and remote participation.  That is, for every IETF
meeting slot, two of the working groups can see and hear the
meeting. For the 55th IETF, in *addition* to the usual network A/V, text
conferencing will be provided for every working group that meets.

All of the conference rooms will be hosted on

     conference.ietf.jabber.com

and each is named using the official IETF abbreviation found in the
agenda (e.g., "apparea",  "dhc", "forces", and so on -- for all the
examples that follow, we'll use "foobar" as the abbreviation).

Each conference room also has a 'bot which records everything that gets
sent. So, the minute taker can review this information right after the
meeting.


1. Before the meeting:

1.1. If you want to participate

If you don't already have one, get yourself a Jabber client, here are some
suggestions:

     platform    suggestion
     --------    ----------
     win32       http://exodus.jabberstudio.org
     'nix        http://gabber.sf.net
     macos       http://jabberfox.sf.net

When you start the client for the first time, it will eventually ask if
you want to register on a public server. Go ahead and do
that.

If you want to find out more, instead of choosing these defaults, here
are pointers to some additional information:

     list of clients:    http://www.jabber.org/user/clientlist.php
               howto:    http://www.jabber.org/user/userguide/
         server list:    http://www.jabber.org/user/publicservers.php

To make sure everything is running ok, do a "Join Group Chat" with your
Jabber client:

     Group/Room: plenary
     Server:     conference.ietf.jabber.com

This conference room is up and running right now (although probably no
one will be in it when you connect).

1.2. What the Chair does

If you want to make text conferencing available, you'll need to have a
volunteer scribe in the meeting room. The scribe will be typing in a
running commentary as to what's going on in the room (who's presenting,
what question is being asked, etc.)

So, why not send an email out on the mailing list now, before the
meeting, to ask for volunteers?


2. At the meeting

2.1. What the Chair does

When a session starts, the chair asks if someone in the room is willing
to act as "scribe". If no one volunteers, read no further, we're done!

Otherwise, the scribe should do a "Join Group Chat" with their Jabber
client, e.g.,

     Group/Room: foobar
     Server:     conference.ietf.jabber.com


2.2. What the Scribe does

The scribe types in a running commentary as to what's going on in the
room. For example, if a speaker makes a presentation, the scribe types
in the URL for the presentation (more on this in a bit).

Simlarly, during question time, a remote participant can type a question
into the room and the scribe can pass it on to the speaker.


2.3. What each Presenter does

Each presenter should put a copy of their presentation on a web server
somewhere, so remote participants can follow along.


2.4. Where to find the conference log

     http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/foobar/

NOTE: the logging facility will not be active until later this week...
     



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BHuhk25892 for ietf-smime-bks; Tue, 11 Mar 2003 09:56:43 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BHqq325678; Tue, 11 Mar 2003 09:52:52 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.8/8.12.8) with ESMTP id h2BHqeZF006657; Wed, 12 Mar 2003 06:52:40 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h2BHqeY06408; Wed, 12 Mar 2003 06:52:40 +1300
Date: Wed, 12 Mar 2003 06:52:40 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Recommendation on subject matching rules needed..
Cc: [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>

"Vainikainen Saku EINT" <[e-mail]> writes:

>Yes, but then we need to store encryption key and certificate chains. Our
>smartcard has only limited space available, so we would need to recover the
>old encryption keys and certificates to PKCS#12 files or other software
>tokens. 

But why do you need to store all this cruft?  If it's a legacy/superseded
decryption key, all you need is the private-key components for decryption
(usually stored in a highly compact card-specific format) and the
issuerAndSerialNumberHash so you can locate it (in fact for any decryption
key, even a currently active one, you don't actually need to store the cert).
The overhead for the non- private-key components would probably be 50-100
bytes, depending on how much other stuff your PKCS #15 implementation stores
alongside it.  So your card contains the current decryption key and its cert,
and one (or possibly more, although you probably need to ask why the user is
losing that many keys) decryption keys and the index info needed to find them.
The indexing overhead for half a dozen decryption keys is going to be less
than that for a single certificate.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BGopK19131 for ietf-smime-bks; Tue, 11 Mar 2003 08:50:51 -0800 (PST)
Received: from smtp22.kolumbus.fi (smtp22.kolumbus.fi [193.229.0.82]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BGfD317938; Tue, 11 Mar 2003 08:41:13 -0800 (PST)
Received: from dom1-cn1-hki.dom1.epnet (dom1-cn1-hki.dom1.epnet [172.21.176.70]) by smtp22.kolumbus.fi (8.12.8/8.12.4) with ESMTP id h2BGf6I3027541; Tue, 11 Mar 2003 18:41:06 +0200 (EET)
Received: from dom1-mb1-hki.dom1.epnet ([172.21.176.65]) by dom1-cn1-hki.dom1.epnet with Microsoft SMTPSVC(5.0.2195.5329); Tue, 11 Mar 2003 18:41:04 +0200
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: RE: Recommendation on subject matching rules needed..
Date: Tue, 11 Mar 2003 18:41:03 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Recommendation on subject matching rules needed..
Thread-Index: AcLn5/tgp/18ImZSRGi4oKijztq7gQAAJNeA
From: "Vainikainen Saku EINT" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 11 Mar 2003 16:41:04.0321 (UTC) FILETIME=[01CC0B10:01C2E7ED]
X-MailScanner: Found to be clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2BGfJ317940
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 how we do it. And this is why the decryption does not work 
> >since the new enc cert gets a new serial number, ie. the encryption 
> >cert gets reissued, ie. the encryption key pair gets 
> recertified, ie. 
> >cert hash changes. One cannot change the contents of a certificate 
> >without generating a new certificate serial number, ie. issue a new 
> >certificate.
> 
> But why is this a problem?  If you get something addressed to 
> the old cert, you use the old key to decrypt.  If it's for 
> the new cert, you use the new key.  In fact there isn't even 
> any need to keep the old cert around if it's decrypt-only, 
> you mention PKCS #15, well that stores all the index info you 
> need with the key, so you don't need the cert at all.

Yes, but then we need to store encryption key and certificate chains.
Our smartcard has only limited space available, so we would need to
recover the old encryption keys and certificates to PKCS#12 files or
other software tokens. Then again the software tokens tend to be a bit
difficult since you have to store them somewhere (disk/cd-rom/whatever,
preferrably a read-only media) to deliver them to the user.

Then in order to use the keys, the user has to import them to his/her
user profile or disk to have them available. And since roaming profiles
are not so common (at least in our environment) copies of the keys
(along with automatic password managers memorizing the passphrases) lay
around in multiple workstations, which is not good in sense of privacy.

Unfortunately most of the software we are using uses Microsoft
CryptoAPI, which hides all PKCS#15 info quite efficiently, thus forcing
the software to use the key usage info stored in the certs.
 
> >Our card has following PKCS#15 key usages on the private keys:
> 
> Have you actually tested all the combinations with your 
> software?  That is, added two certs that differ only in 
> encryption vs.signature usage and then see what the app does 
> if asked for a signature or encryption cert?  Some of the 
> people I pointed out problems to were surprised at the 
> problems, since things seemed to work OK (meaning that the 
> app just grabbed the first key it found and used that, so 
> everything appeared to work fine).

No - since we issue only one cert per key at a time, and we don't issue
multiple certificates with identical serial numbers. And the apps we are
using allow us to choose the certificate (=key) to be used, although
they do some filtering based on key usage information found in the
certificates.

Saku.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BGAwL16277 for ietf-smime-bks; Tue, 11 Mar 2003 08:10:58 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BG53315936; Tue, 11 Mar 2003 08:05:04 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.8/8.12.8) with ESMTP id h2BG4rZF005191; Wed, 12 Mar 2003 05:04:53 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h2BG4qQ06135; Wed, 12 Mar 2003 05:04:52 +1300
Date: Wed, 12 Mar 2003 05:04:52 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Recommendation on subject matching rules needed..
Cc: [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>

"Vainikainen Saku EINT" <[e-mail]> writes:

>This is how we do it. And this is why the decryption does not work since the
>new enc cert gets a new serial number, ie. the encryption cert gets reissued,
>ie. the encryption key pair gets recertified, ie. cert hash changes. One
>cannot change the contents of a certificate without generating a new
>certificate serial number, ie. issue a new certificate.

But why is this a problem?  If you get something addressed to the old cert,
you use the old key to decrypt.  If it's for the new cert, you use the new
key.  In fact there isn't even any need to keep the old cert around if it's
decrypt-only, you mention PKCS #15, well that stores all the index info you
need with the key, so you don't need the cert at all.

>Our card has following PKCS#15 key usages on the private keys:

Have you actually tested all the combinations with your software?  That is,
added two certs that differ only in encryption vs.signature usage and then see
what the app does if asked for a signature or encryption cert?  Some of the
people I pointed out problems to were surprised at the problems, since things
seemed to work OK (meaning that the app just grabbed the first key it found
and used that, so everything appeared to work fine).

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BFPnk12244 for ietf-smime-bks; Tue, 11 Mar 2003 07:25:49 -0800 (PST)
Received: from smtp23.kolumbus.fi (smtp23.kolumbus.fi [193.229.0.81]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BFPg312239; Tue, 11 Mar 2003 07:25:42 -0800 (PST)
Received: from dom1-cn1-hki.dom1.epnet (dom1-cn1-hki.dom1.epnet [172.21.176.70]) by smtp23.kolumbus.fi (8.12.8/8.12.4) with ESMTP id h2BFPa9b010710; Tue, 11 Mar 2003 17:25:36 +0200 (EET)
Received: from dom1-mb1-hki.dom1.epnet ([172.21.176.65]) by dom1-cn1-hki.dom1.epnet with Microsoft SMTPSVC(5.0.2195.5329); Tue, 11 Mar 2003 17:25:35 +0200
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: RE: Recommendation on subject matching rules needed..
Date: Tue, 11 Mar 2003 17:25:35 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Recommendation on subject matching rules needed..
Thread-Index: AcLn3noPJeZuBm3aRACxs8mv9nNhdAAADFUQ
From: "Vainikainen Saku EINT" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 11 Mar 2003 15:25:35.0381 (UTC) FILETIME=[7656A450:01C2E7E2]
X-MailScanner: Found to be clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2BFPl412241
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>

> >Our cards (=certs) are valid for three years. If the card 
> has been in 
> >use for 2 years when we reissue it with recovered enc key, 
> we need to 
> >reissue the enc cert also - otherwise the recovered enc key 
> cert could 
> >be usable only for one year whereas the other certs would be 
> usable for 
> >three years.
> 
> Why not just leave the decryption key as is and issue a new 
> 3-year decryption cert?  This in effect is what I do in my 
> code (with the date-based transparent rollover).

This is how we do it. And this is why the decryption does not work since
the new enc cert gets a new serial number, ie. the encryption cert gets
reissued, ie. the encryption key pair gets recertified, ie. cert hash
changes. One cannot change the contents of a certificate without
generating a new certificate serial number, ie. issue a new certificate.

> >Also - if we pile up all the previous enc certs to the card 
> along with 
> >the new cert, we run out of card space as well as introduce new 
> >problems since the apps usually don't iterate though all the 
> certs and 
> >end up using the first cert available.
> 
> Can you fit 4 keys?

Yep - but we don't want to do that because when we take that path we
need to have space for (not infinite but anyways) many keys, since if
start maintaining key chains (generating a new key on every reissue and
attaching it to the chain of old enc keys) there is no end to it..
 
> (On a completely unrelated topic, are you sure the software 
> you're using is  able to make sense of the NR key there?  A 
> lot of software is totally  incapable of distinguishing 
> between signature and NR keys, and just takes the  first one 
> that it finds with {signature,NR} enabled.  For that matter, 
> I've  found a number of card issuers in [looks at sender's 
> country code], uhh,  well, Scandinavia who set PKCS #11 key 
> usage bits incorrectly on cards, so  you get crypto keys 
> marked as signing keys and vice versa, or all keys marked  as 
> crypto or signing keys, or other oddities, and no-one even 
> notices that  they're encrypting with the NR key.  The point 
> is that if your software can't  differentiate between 
> signature and NR (or even all three key types), you  could 
> dump the NR key and add an extra encryption key instead).

Our card has following PKCS#15 key usages on the private keys:

auth: 	sign, sign-recover, unwrap
nonrep:	nonrepudiation
enc:		decrypt, unwrap

Certs go as follows:

auth:		digital signature, key encipherment
nonrep:	nonrepudiation
enc:		key encripherment, data encipherment

Extended key usages on certs:

auth:		Client Authentication (1.3.6.1.5.5.7.3.2)
		Secure Email (1.3.6.1.5.5.7.3.4)
		IP security IKE intermediate (1.3.6.1.5.5.8.2.2)
		Smart Card Logon (1.3.6.1.4.1.311.20.2.2)

nonrep:	-

enc:		Secure Email (1.3.6.1.5.5.7.3.4)
		IP security IKE intermediate (1.3.6.1.5.5.8.2.2)

Authentication key is used in SSL authentication, W2k logon, VPN
authentication and email signing (=authentication).

Nonrepudiation key is not yet used anywhere (lack of document management
software supporting smartcards).

Encryption key is used in e-mail encryption as well as in
disk/folder/file encryption (option to use in VPN connections as well).

Saku.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BF24C11050 for ietf-smime-bks; Tue, 11 Mar 2003 07:02:04 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BEv0310809; Tue, 11 Mar 2003 06:57:00 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.8/8.12.8) with ESMTP id h2BEunZF003827; Wed, 12 Mar 2003 03:56:49 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h2BEup205527; Wed, 12 Mar 2003 03:56:51 +1300
Date: Wed, 12 Mar 2003 03:56:51 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Recommendation on subject matching rules needed..
Cc: [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>

[Also CC'd to S/MIME]

"Vainikainen Saku EINT" <[e-mail]> writes:

>>>It seems that all the software we have tested (eg. MSoft, Utimaco)
>>
>>Everyone, not just those two.
>
>OK - this is more or less what I assumed :( Do you know if there is any work
>being done on this subject in terms of a recommendation
>paper/draft/something?

See my previous message.  It's really an application/policy issue, I don't
know if there's much to say in standards except maybe to post a skull and
crossbones next to a description of the problem to let people know what
they're in for.

>Our cards (=certs) are valid for three years. If the card has been in use for
>2 years when we reissue it with recovered enc key, we need to reissue the enc
>cert also - otherwise the recovered enc key cert could be usable only for one
>year whereas the other certs would be usable for three years.

Why not just leave the decryption key as is and issue a new 3-year decryption
cert?  This in effect is what I do in my code (with the date-based transparent
rollover).

>Also - if we pile up all the previous enc certs to the card along with the
>new cert, we run out of card space as well as introduce new problems since
>the apps usually don't iterate though all the certs and end up using the
>first cert available.

Can you fit 4 keys?

(On a completely unrelated topic, are you sure the software you're using is
 able to make sense of the NR key there?  A lot of software is totally
 incapable of distinguishing between signature and NR keys, and just takes the
 first one that it finds with {signature,NR} enabled.  For that matter, I've
 found a number of card issuers in [looks at sender's country code], uhh,
 well, Scandinavia who set PKCS #11 key usage bits incorrectly on cards, so
 you get crypto keys marked as signing keys and vice versa, or all keys marked
 as crypto or signing keys, or other oddities, and no-one even notices that
 they're encrypting with the NR key.  The point is that if your software can't
 differentiate between signature and NR (or even all three key types), you
 could dump the NR key and add an extra encryption key instead).

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BEqkA10679 for ietf-smime-bks; Tue, 11 Mar 2003 06:52:46 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BEj1310451; Tue, 11 Mar 2003 06:45:01 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.8/8.12.8) with ESMTP id h2BEipZF003661; Wed, 12 Mar 2003 03:44:51 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h2BEipt05508; Wed, 12 Mar 2003 03:44:51 +1300
Date: Wed, 12 Mar 2003 03:44:51 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: RE: Recommendation on subject matching rules needed..
Cc: [e-mail], [e-mail], [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>

[CC'd to the S/MIME list, this is really an S/MIME and not a PKIX issue.  For
 those just joining us, the issue is what to do when you re-certify your
 encryption key (NB: Someone else is doing this, not me :-)]

"Olle Mulmo" <[e-mail]> writes:

>I don't follow the logic here... If hash of issuer+serial is used, 

Just the issuerAndSerialNumber, there's no hash.

>won't the same issue happen upon revalidation of the key pair (that is, when
>the original certificate expires)? Or am I more or less required to do a key
>replacement operation (or changeover, or whatever the correct terminology is)
>at that point?

It's a black hole.  The method I've seen used a few times (because it works
with pretty much anything) is some variation of running two systems, one with
the clock set back so it can still use the old key, and another one with the
clock running at the current time for the new key.  Every vendor does it
differently.  Some require a system rebuild (the equivalent of a
reformat+reinstall-Windows operation for the crypto/PKI software).  Some
handle both keys, with various amounts of manual intervention.  I've seen one
group that have a Grand Key Changeover day when everyone has to roll over
their keys (well, certs), and people are instructed not to send any critical
encrypted messages at that time.

My code allows multiple keys and preferentially grabs the most recent (that
is, currently-valid) one, since that's the behaviour the most users asked for.
On the decrypting side, it looks up the key purely by issuerAndSerialNumber
(ignoring date issues), so you can decrypt with both the old and new key,
depending on what the sender used.  That way you can swap in a new key at any
time and it just works (if you even happen to be reading PKCS #15/ISO 7816-15
and wonder why there are validity times attached to private keys, this is
why).

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2B1q3511962 for ietf-smime-bks; Mon, 10 Mar 2003 17:52:03 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.6) with SMTP id h2B1q2311958 for <[e-mail]>; Mon, 10 Mar 2003 17:52:02 -0800 (PST)
Received: (qmail 12172 invoked from network); 11 Mar 2003 01:51:47 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (12.148.142.25) by woodstock.binhost.com with SMTP; 11 Mar 2003 01:51:47 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 10 Mar 2003 20:51:58 -0500
To: "Enzo Michelangeli" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-sip-smime-aes-00.txt
Cc: [e-mail]
In-Reply-To: <005e01c2e76a$ca40f700$0200000a@emnb>
References: <[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>

Enzo:

> > CMS no longer includes any mandatory to implement algorithms.  This was
> > done so that each application could assign the best algorithms for their
> > environment.
> >
> > For S/MIME version 3.1, the mandatory to implement encryption algorithm is
> > Triple-DES.  I do not expect this to change.  However, there has been
> > discussion about making AES a SHOULD implement algorithm.  The "Use of AES
> > with CMS" specification is finally nearly finished.  This is intended to
> > send a message to implementors that AES will probably become a MUST
> > implement algorithm in the future.  At that time, AES would become MUST and
> > Triple-DES would become SHOULD (to preserve interoperability with old
> > algorithms).
>
>Is backwards interoperability considered a SHOULD? I would think that it's
>important enough to make it a MUST (at least for decryption of old
>messages).

This depends on time scale.  I agree that backwards compatibility is very, 
very important.  However, at some point, the current MUST will become a 
SHOULD and eventually become a MAY.  For S/MIME it would be possible to be 
even more graceful.  For example:

    For transmission, the agent MUST implement AES.

    For reception, the agent MUST implement AES and Triple-DES.

Russ




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2B18vP10855 for ietf-smime-bks; Mon, 10 Mar 2003 17:08:57 -0800 (PST)
Received: from c007.snv.cp.net (h008.c007.snv.cp.net [209.228.33.236]) by above.proper.com (8.11.6/8.11.6) with SMTP id h2B18t310851 for <[e-mail]>; Mon, 10 Mar 2003 17:08:56 -0800 (PST)
Received: (cpmta 26279 invoked from network); 10 Mar 2003 17:08:58 -0800
Received: from 203.78.80.131 (HELO emnb) by smtp.i-t-vision.com (209.228.33.236) with SMTP; 10 Mar 2003 17:08:58 -0800
X-Sent: 11 Mar 2003 01:08:58 GMT
Message-ID: <005e01c2e76a$ca40f700$0200000a@emnb>
Reply-To: "Enzo Michelangeli" <[e-mail]>
From: "Enzo Michelangeli" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-sip-smime-aes-00.txt
Date: Tue, 11 Mar 2003 09:07:38 +0800
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 6.00.2800.1106
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>

----- Original Message -----
From: "Russ Housley" <[e-mail]>
To: "Peterson, Jon" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, March 11, 2003 7:28 AM
Subject: RE: I-D ACTION:draft-ietf-sip-smime-aes-00.txt


> Jon:
>
> CMS no longer includes any mandatory to implement algorithms.  This was
> done so that each application could assign the best algorithms for their
> environment.
>
> For S/MIME version 3.1, the mandatory to implement encryption algorithm is
> Triple-DES.  I do not expect this to change.  However, there has been
> discussion about making AES a SHOULD implement algorithm.  The "Use of AES
> with CMS" specification is finally nearly finished.  This is intended to
> send a message to implementors that AES will probably become a MUST
> implement algorithm in the future.  At that time, AES would become MUST
and
> Triple-DES would become SHOULD (to preserve interoperability with old
> algorithms).

Is backwards interoperability considered a SHOULD? I would think that it's
important enough to make it a MUST (at least for decryption of old
messages).

Enzo



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2ANTku08067 for ietf-smime-bks; Mon, 10 Mar 2003 15:29:46 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.6) with SMTP id h2ANTj308063 for <[e-mail]>; Mon, 10 Mar 2003 15:29:45 -0800 (PST)
Received: (qmail 7057 invoked from network); 10 Mar 2003 23:29:28 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (12.148.142.25) by woodstock.binhost.com with SMTP; 10 Mar 2003 23:29:28 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 10 Mar 2003 18:28:12 -0500
To: "Peterson, Jon" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-sip-smime-aes-00.txt
Cc: [e-mail]
In-Reply-To: <[e-mail] tar.com>
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>

Jon:

CMS no longer includes any mandatory to implement algorithms.  This was 
done so that each application could assign the best algorithms for their 
environment.

For S/MIME version 3.1, the mandatory to implement encryption algorithm is 
Triple-DES.  I do not expect this to change.  However, there has been 
discussion about making AES a SHOULD implement algorithm.  The "Use of AES 
with CMS" specification is finally nearly finished.  This is intended to 
send a message to implementors that AES will probably become a MUST 
implement algorithm in the future.  At that time, AES would become MUST and 
Triple-DES would become SHOULD (to preserve interoperability with old 
algorithms).

Russ

At 06:50 PM 3/4/2003 -0500, Peterson, Jon wrote:


>I'm glad that the draft is some of interest to this WG, since we could
>probably use some advice from the S/MIME experts on our direction.
>
>This document proposes to profile S/MIME for SIP, specifically by exchanging
>the mandatory Triple-DES encryption algorithm requirement for AES. Some of
>the reasons why AES would be a better fit for SIP are given in the draft.
>There is, however, some concern that this might lead to non-interoperability
>with standard S/MIME stacks, and so on.
>
>I see that rfc2633bis 2.7 makes Triple-DES mandatory. Is it likely that
>S/MIME down the road will require AES? Does the proposal in this draft seem
>like a wrong-headed profile to this WG?
>
>Jon Peterson
>NeuStar, Inc.
>
> > -----Original Message-----
> > From: Paul Hoffman / IMC [mailto:[e-mail]]
> > Sent: Tuesday, March 04, 2003 10:15 AM
> > To: [e-mail]
> > Subject: Fwd: I-D ACTION:draft-ietf-sip-smime-aes-00.txt
> >
> >
> >
> > Of interest to this WG...
> >
> > >To: IETF-Announce: ;
> > >Cc: [e-mail]
> > >From: [e-mail]
> > >Reply-to: [e-mail]
> > >Subject: I-D ACTION:draft-ietf-sip-smime-aes-00.txt
> > >Date: Thu, 27 Feb 2003 07:45:27 -0500
> > >Sender: [e-mail]
> > >
> > >
> > >
> > >A New Internet-Draft is available from the on-line Internet-Drafts
> > >directories.
> > >This draft is a work item of the Session Initiation Protocol Working
> > >Group of the IETF.
> > >
> > >     Title           : S/MIME AES Requirement for SIP
> > >     Author(s)       : J. Peterson
> > >     Filename        : draft-ietf-sip-smime-aes-00.txt
> > >     Pages           : 6
> > >     Date            : 2003-2-26
> > >
> > >RFC3261 currently specifies 3DES as the required minimum ciphersuite
> > >for implementations of S/MIME in SIP.  This document updates the
> > >normative guidance of RFC3261 to require the Advanced Encryption
> > >Standard (AES) for S/MIME.
> > >
> > >A URL for this Internet-Draft is:
> > >http://www.ietf.org/internet-drafts/draft-ietf-sip-smime-aes-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-sip-smime-aes-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-sip-smime-aes-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.
> > >
> > >
> > >[The following attachment must be fetched by mail. Command-click the
> > >URL below and send the resulting message to get the attachment.]
> > ><mailto:[e-mail]?body=ENCODING%20mime%0D%0AFILE%20/i
>nternet-drafts/draft-ietf-sip-smime-aes-00.txt>
> >[The following attachment must be fetched by ftp.  Command-click the
> >URL below to ask your ftp client to fetch it.]
> ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-sip-smime-aes-00.txt>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h27MiLf22521 for ietf-smime-bks; Fri, 7 Mar 2003 14:44:21 -0800 (PST)
Received: from mx2.pacifier.net (mx2.pacifier.net [64.255.237.182]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27MiJ322515 for <[e-mail]>; Fri, 7 Mar 2003 14:44:19 -0800 (PST)
Received: from smtp4.pacifier.net (smtp4 [64.255.237.174]) by mx2.pacifier.net (Postfix) with ESMTP id DC62F6A4D9; Fri,  7 Mar 2003 14:44:21 -0800 (PST)
Received: from revelation (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp4.pacifier.net (Postfix) with ESMTP id 157746A427; Fri,  7 Mar 2003 14:27:00 -0800 (PST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-camellia-01.txt
Date: Fri, 7 Mar 2003 14:41:37 -0800
Message-ID: <001601c2e4fa$b6fcc150$[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>

Gentlemen,

This draft looks complete except for the section on SMIMECapabilities.

Either your text or your DER encoded values need to be changed.  You
have stated that 

	CamelliaSMimeCapabilty ::= NULL 

And you have stated that

	The parameter associated with this OID MUST be
CamelliaSMimeCapability.

This means that the first encoding should be 

128          30 0f 06 0b 2a 83 08 8c 9a 4b 3d 01 01 01 02 05 00

This is because NULL is a defined value within the DER encoding system
having a tag value of 5 and a length of 0.   I have just looked back at
the AES document and found that I have this section incorrect as well.
I will need to update it.

jim


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> Sent: Friday, March 07, 2003 12:38 PM
> To: IETF-Announce:
> Cc: [e-mail]
> Subject: I-D ACTION:draft-ietf-smime-camellia-01.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 Camellia Encryption 
> Algorithm in CMS
> 	Author(s)	: S. Moriai, A. Kato
> 	Filename	: draft-ietf-smime-camellia-01.txt
> 	Pages		: 11
> 	Date		: 2003-3-7
> 	
> This document specifies how to incorporate the Camellia encryption
> algorithm into the S/MIME Cryptographic Message Syntax (CMS) as an
> additional algorithm for symmetric encryption.  The relevant object
> identifiers (OIDs) and processing steps are provided so that
> Camellia may be used in the CMS specification (RFC 3369, RFC 3370)
> for content and key encryption.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-smime-camellia-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-camellia-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-camellia-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.
> 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h27Kdnh17887 for ietf-smime-bks; Fri, 7 Mar 2003 12:39:49 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27Kdm317883 for <[e-mail]>; Fri, 7 Mar 2003 12:39:48 -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 PAA29789; Fri, 7 Mar 2003 15:37:43 -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-camellia-01.txt
Date: Fri, 07 Mar 2003 15:37:43 -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 Camellia Encryption Algorithm in CMS
	Author(s)	: S. Moriai, A. Kato
	Filename	: draft-ietf-smime-camellia-01.txt
	Pages		: 11
	Date		: 2003-3-7
	
This document specifies how to incorporate the Camellia encryption
algorithm into the S/MIME Cryptographic Message Syntax (CMS) as an
additional algorithm for symmetric encryption.  The relevant object
identifiers (OIDs) and processing steps are provided so that
Camellia may be used in the CMS specification (RFC 3369, RFC 3370)
for content and key encryption.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-camellia-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.6) id h24NoCg25122 for ietf-smime-bks; Tue, 4 Mar 2003 15:50:12 -0800 (PST)
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24NoAX25115; Tue, 4 Mar 2003 15:50:11 -0800 (PST)
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h24No8C12457; Tue, 4 Mar 2003 23:50:08 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <ZH2JRJXJ>; Tue, 4 Mar 2003 18:50:12 -0500
Message-ID: <[e-mail]>
From: "Peterson, Jon" <[e-mail]>
To: "'Paul Hoffman / IMC'" <[e-mail]>, [e-mail]
Subject: RE: I-D ACTION:draft-ietf-sip-smime-aes-00.txt
Date: Tue, 4 Mar 2003 18:50:11 -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>

I'm glad that the draft is some of interest to this WG, since we could
probably use some advice from the S/MIME experts on our direction.

This document proposes to profile S/MIME for SIP, specifically by exchanging
the mandatory Triple-DES encryption algorithm requirement for AES. Some of
the reasons why AES would be a better fit for SIP are given in the draft.
There is, however, some concern that this might lead to non-interoperability
with standard S/MIME stacks, and so on.

I see that rfc2633bis 2.7 makes Triple-DES mandatory. Is it likely that
S/MIME down the road will require AES? Does the proposal in this draft seem
like a wrong-headed profile to this WG?

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:[e-mail]]
> Sent: Tuesday, March 04, 2003 10:15 AM
> To: [e-mail]
> Subject: Fwd: I-D ACTION:draft-ietf-sip-smime-aes-00.txt
> 
> 
> 
> Of interest to this WG...
> 
> >To: IETF-Announce: ;
> >Cc: [e-mail]
> >From: [e-mail]
> >Reply-to: [e-mail]
> >Subject: I-D ACTION:draft-ietf-sip-smime-aes-00.txt
> >Date: Thu, 27 Feb 2003 07:45:27 -0500
> >Sender: [e-mail]
> >
> >
> >
> >A New Internet-Draft is available from the on-line Internet-Drafts 
> >directories.
> >This draft is a work item of the Session Initiation Protocol Working 
> >Group of the IETF.
> >
> >	Title		: S/MIME AES Requirement for SIP
> >	Author(s)	: J. Peterson
> >	Filename	: draft-ietf-sip-smime-aes-00.txt
> >	Pages		: 6
> >	Date		: 2003-2-26
> >
> >RFC3261 currently specifies 3DES as the required minimum ciphersuite
> >for implementations of S/MIME in SIP.  This document updates the
> >normative guidance of RFC3261 to require the Advanced Encryption
> >Standard (AES) for S/MIME.
> >
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-ietf-sip-smime-aes-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-sip-smime-aes-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-sip-smime-aes-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.
> >
> >
> >[The following attachment must be fetched by mail. Command-click the 
> >URL below and send the resulting message to get the attachment.]
> ><mailto:[e-mail]?body=ENCODING%20mime%0D%0AFILE%20/i
nternet-drafts/draft-ietf-sip-smime-aes-00.txt>
>[The following attachment must be fetched by ftp.  Command-click the 
>URL below to ask your ftp client to fetch it.]
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-sip-smime-aes-00.txt>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24JKg613162 for ietf-smime-bks; Tue, 4 Mar 2003 11:20:42 -0800 (PST)
Received: from [63.202.92.157] (adsl-66-123-66-37.dsl.pltn13.pacbell.net [66.123.66.37]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24JKfX13153 for <[e-mail]>; Tue, 4 Mar 2003 11:20:41 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210536ba8a9d738a18@[63.202.92.157]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Tue, 4 Mar 2003 10:14:32 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Fwd: I-D ACTION:draft-ietf-sip-smime-aes-00.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Of interest to this WG...

>To: IETF-Announce: ;
>Cc: [e-mail]
>From: [e-mail]
>Reply-to: [e-mail]
>Subject: I-D ACTION:draft-ietf-sip-smime-aes-00.txt
>Date: Thu, 27 Feb 2003 07:45:27 -0500
>Sender: [e-mail]
>
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Session Initiation Protocol Working 
>Group of the IETF.
>
>	Title		: S/MIME AES Requirement for SIP
>	Author(s)	: J. Peterson
>	Filename	: draft-ietf-sip-smime-aes-00.txt
>	Pages		: 6
>	Date		: 2003-2-26
>
>RFC3261 currently specifies 3DES as the required minimum ciphersuite
>for implementations of S/MIME in SIP.  This document updates the
>normative guidance of RFC3261 to require the Advanced Encryption
>Standard (AES) for S/MIME.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-sip-smime-aes-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-sip-smime-aes-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-sip-smime-aes-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.
>
>
>[The following attachment must be fetched by mail. Command-click the 
>URL below and send the resulting message to get the attachment.]
><mailto:[e-mail]?body=ENCODING%20mime%0D%0AFILE%20/internet-drafts/draft-ietf-sip-smime-aes-00.txt>
>[The following attachment must be fetched by ftp.  Command-click the 
>URL below to ask your ftp client to fetch it.]
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-sip-smime-aes-00.txt>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24JKgE13159 for ietf-smime-bks; Tue, 4 Mar 2003 11:20:42 -0800 (PST)
Received: from [63.202.92.157] (adsl-66-123-66-37.dsl.pltn13.pacbell.net [66.123.66.37]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24JKeX13149 for <[e-mail]>; Tue, 4 Mar 2003 11:20:40 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210535ba8a9c915519@[63.202.92.157]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Tue, 4 Mar 2003 10:11:47 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Fwd: I-D ACTION:draft-housley-cms-fw-wrap-00.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This isn't about S/MIME, but it is about an interesting use for CMS. 
It would be great to get this right the first time, so CMS folks 
might want to poke at this a bit.

>To: IETF-Announce: ;
>From: [e-mail]
>Reply-to: [e-mail]
>Subject: I-D ACTION:draft-housley-cms-fw-wrap-00.txt
>Date: Thu, 13 Feb 2003 13:31:28 -0500
>Sender: [e-mail]
>
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>	Title		: Using CMS to Protect Firmware Packages
>	Author(s)	: R. Housley
>	Filename	: draft-housley-cms-fw-wrap-00.txt
>	Pages		: 36
>	Date		: 2003-2-12
>
>This document describes the use of the Cryptographic Message Syntax
>(CMS) to protect firmware packages.  A digital signature is used to
>protect the firmware package from undetected modification and provide
>data origin authentication.  Encryption is optionally used to protect
>the firmware from disclosure, and compression is optionally used to
>reduce the size of the protected firmware package.  A firmware
>package loading signed receipt can optionally be generated to
>acknowledge the successful loading of a firmware package.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-housley-cms-fw-wrap-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-housley-cms-fw-wrap-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-housley-cms-fw-wrap-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.
>
>
>[The following attachment must be fetched by mail. Command-click the 
>URL below and send the resulting message to get the attachment.]
><mailto:[e-mail]?body=ENCODING%20mime%0D%0AFILE%20/internet-drafts/draft-housley-cms-fw-wrap-00.txt>
>[The following attachment must be fetched by ftp.  Command-click the 
>URL below to ask your ftp client to fetch it.]
><ftp://ftp.ietf.org/internet-drafts/draft-housley-cms-fw-wrap-00.txt>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h23LxCm20113 for ietf-smime-bks; Mon, 3 Mar 2003 13:59:12 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.6) with SMTP id h23LxBX20101 for <[e-mail]>; Mon, 3 Mar 2003 13:59:11 -0800 (PST)
Received: (qmail 15298 invoked from network); 3 Mar 2003 21:58:58 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.173.138) by woodstock.binhost.com with SMTP; 3 Mar 2003 21:58:58 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 03 Mar 2003 16:58:52 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RFC 3369 Errata
Cc: [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>

Dear RFC Editor:

Please post the errata.  An error of omission has just been discovered in 
RFC 3369.  Several object identifiers (OIDs) have been omitted from the 
ASN.1 module in section 12.1; however, these OIDs are fully discussed in 
the body of the document.

On page 46 of RFC 3369, the following object identifiers need to be 
inserted before the end of the ASN.1 module.  That is, the following lines 
need to be inserted before:
"END -- of CryptographicMessageSyntax"

Theses are the lines that need to be inserted:

       -- Content Type Object Identifiers

       id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 }

       id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }

       id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }

       id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
           us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }

       id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
           us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }

       id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
           us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }

       id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
           us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
           ct(1) 2 }

I have compiled the resulting ASN.1 module, and it does not introduce any 
syntax errors.

Thanks,
    Russ



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h23IhfG10274 for ietf-smime-bks; Mon, 3 Mar 2003 10:43:41 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.6) with SMTP id h23IheX10270 for <[e-mail]>; Mon, 3 Mar 2003 10:43:40 -0800 (PST)
Received: (qmail 6085 invoked from network); 3 Mar 2003 18:43:27 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.33.121) by woodstock.binhost.com with SMTP; 3 Mar 2003 18:43:27 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 03 Mar 2003 13:43:39 -0500
To: [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: Agenda for the S/MIME WG Session at IETF 56
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>

Here is the agenda for the S/MIME WG Session at IETF 56 in San Francisco.

Russ

= = = = = = = = = =

Introductions				Russ Housley
Working Group Status			Russ Housley
CMS and ESS Examples Update	Paul Hoffman
MSGbis and CERTbis Update		Blake Ramsdell
Interoperability Matrix Update		Jim Schaad
RSA PSS Signatures			Jim Schaad
SIP and SIPPING			Rohan Mahy
Wrap up				Russ Housley



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h22KqJE19331 for ietf-smime-bks; Sun, 2 Mar 2003 12:52:19 -0800 (PST)
Received: from mx2.pacifier.net (mx2.pacifier.net [64.255.237.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h22KqIY19327 for <[e-mail]>; Sun, 2 Mar 2003 12:52:18 -0800 (PST)
Received: from smtp4.pacifier.net (smtp4 [64.255.237.174]) by mx2.pacifier.net (Postfix) with ESMTP id 668C76AA18 for <[e-mail]>; Sun,  2 Mar 2003 12:52:20 -0800 (PST)
Received: from revelation (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp4.pacifier.net (Postfix) with ESMTP id D3B766A428 for <[e-mail]>; Sun,  2 Mar 2003 12:35:10 -0800 (PST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>
Subject: RFC 3369 Flaw - No Content OIDs
Date: Sun, 2 Mar 2003 12:49:45 -0800
Message-ID: <000301c2e0fd$4282c7d0$[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
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>

In the process of trying to get the last pieces tied up on the interop
report, I found that I had not updated on of my base ASN.1 modules from
RFC 2630 to RFC 3369.  When I did this I discovered that the content
OIDs were dropped in the process of seperating out the algorithm OIDs.
This needs to be fixed before we can progress the document to the next
level.

Jim Schaad