Subject: I-D ACTION:draft-ietf-smime-symkeydist-08.txt

From: [email-masked]
Date: Wed, 18 Dec 2002 08:04:08 -0500

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

	Title		: CMS Symmetric Key Management and Distribution
	Author(s)	: S. Turner
	Filename	: draft-ietf-smime-symkeydist-08.txt
	Pages		: 81
	Date		: 2002-12-16
	
This document describes a mechanism to manage (i.e., setup,
distribute, and rekey) keys used with symmetric cryptographic
algorithms. Also defined herein is a mechanism to organize users
into groups to support distribution of encrypted content using
symmetric cryptographic algorithms. The mechanisms use the
Cryptographic Message Syntax (CMS) protocol [2] and Certificate
Management Message over CMS (CMC) protocol [3] to manage the
symmetric keys. Any member of the group can then later use this
distributed shared key to decrypt other CMS encrypted objects with
the symmetric key. This mechanism has been developed to support
S/MIME Mail List Agents (MLAs).

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Sean P. Turner" <[email-masked]>
Date: Fri, 20 Dec 2002 10:39:25 -0500

All,

The posted new draft addresses two comments from the IESG:

- The first one was that the references needed to be broken out to indicate
which documents are informative and which are normative.

- The second was a concern about reply attacks.  We added the CMS signingTime
attribute to ever signed message.

Cheers,

spt

[email-masked] wrote:

Send a message to:
[email-masked].
In the body type:

Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBKFi6X16598 for ietf-smime-bks; Fri, 20 Dec 2002 07:44:06 -0800 (PST)
Received: from tweety (pool-151-200-26-46.res.east.verizon.net [151.200.26.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBKFi4o16593 for ; Fri, 20 Dec 2002 07:44:04 -0800 (PST)
Received: from [192.168.0.12] by tweety (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Fri, 20 Dec 2002 10:39:27 -0500
Message-ID: <[email-masked]>
Date: Fri, 20 Dec 2002 10:39:25 -0500
From: "Sean P. Turner"
Organization: IECA, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-symkeydist-08.txt
References: <[email-masked]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

All,

The posted new draft addresses two comments from the IESG:

- The first one was that the references needed to be broken out to indicate
which documents are informative and which are normative.

- The second was a concern about reply attacks.  We added the CMS signingTime
attribute to ever signed message.

Cheers,

spt

[email-masked] wrote:

Send a message to:
[email-masked].
In the body type:

Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBJEVJe07928 for ietf-smime-bks; Thu, 19 Dec 2002 06:31:19 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id gBJEVIo07922 for ; Thu, 19 Dec 2002 06:31:18 -0800 (PST)
Received: (qmail 6154 invoked from network); 19 Dec 2002 14:31:04 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.218.137) by woodstock.binhost.com with SMTP; 19 Dec 2002 14:31:04 -0000
Message-Id: <[email-masked]>
X-Sender: [email-masked] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 18 Dec 2002 14:33:47 -0500
To: KATO Akihiro , [email-masked]
From: Russ Housley
Subject: Re: Comments on draft-ietf-smime-camellia
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Kato:

I agree with Jim.

An algorithm identifier has the following syntax:

AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL }

Absent means that the optional parameters are not present.

NULL means that the fields is present with a null type (a tag of 0x05) and
a length of zero.

Russ

At 01:45 PM 12/17/2002 +0900, KATO Akihiro wrote:

>Hi Jim
>
>On Wed, 20 Nov 2002 13:51:19 -0500
>"Jim Schaad" wrote:
>
>snip
>
> > 7. Section 2.2: I strongly suggest that you change the parameters for
> > the key wrap algorithm OIDs to be ABSENT rather than NULL.
>
>How is ABSENT that you say the meaning that says? We are using the word
>called NULL is 'the parameter does not exist,but parameter field exist'.
>
>I think that this one is good. It is because it becomes clear that the
>parameter does not exist.
>
>On the other hand, there is the possibility that is interpreted that
>default is used, if place itself that designates the parameter is absent.
>
>Regards.
>--
>- KATO Akihiro
> + NTT Software Corporation
> + Internet Technology Laboratory

Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBIEFfV09172 for ietf-smime-bks; Wed, 18 Dec 2002 06:15:41 -0800 (PST)
Received: from jupiter.jmi.co.kr ([211.45.79.102]) by above.proper.com (8.11.6/8.11.3) with SMTP id gBIEFbo09165 for ; Wed, 18 Dec 2002 06:15:40 -0800 (PST)
Received: (qmail 3707 invoked by uid 525); 18 Dec 2002 23:16:29 +0900
Received: (qmail 3681 invoked from network); 18 Dec 2002 23:15:35 +0900
Received: from unknown (HELO polo.jmi.co.kr) (211.45.79.31) by 0 with SMTP; 18 Dec 2002 23:15:35 +0900
Received: from ran.ietf.org (ran.ietf.org [132.151.6.60]) by polo.jmi.co.kr (8.9.0/8.9.0) with ESMTP id XAA23075 for ; Wed, 18 Dec 2002 23:18:40 +0900 (KST)
Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18Oe3r-0006fF-00 for [email-masked]; Wed, 18 Dec 2002 08:16:31 -0500
Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18OdvE-0006Qe-00 for [email-masked]; Wed, 18 Dec 2002 08:07:36 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04590; Wed, 18 Dec 2002 08:04:08 -0500 (EST)
Message-Id: <[email-masked]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-symkeydist-08.txt
Date: Wed, 18 Dec 2002 08:04:08 -0500
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--NextPart

Send a message to:
[email-masked].
In the body type:

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

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

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-symkeydist-08.txt

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

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBID79f26318 for ietf-smime-bks; Wed, 18 Dec 2002 05:07:09 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBID78o26306 for ; Wed, 18 Dec 2002 05:07:08 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04590; Wed, 18 Dec 2002 08:04:08 -0500 (EST)
Message-Id: <[email-masked]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-symkeydist-08.txt
Date: Wed, 18 Dec 2002 08:04:08 -0500
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--NextPart

Send a message to:
[email-masked].
In the body type:

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

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

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-symkeydist-08.txt

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

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBI2djp06000 for ietf-smime-bks; Tue, 17 Dec 2002 18:39:45 -0800 (PST)
Received: from imc.org ([210.21.34.191]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBI2dOo05987 for ; Tue, 17 Dec 2002 18:39:42 -0800 (PST)
Message-Id: <[email-masked]>
From: [email-masked]
Subject: =?GB2312?B?zOG5qc34wufJ48/xu/o=?=
To: [email-masked]
Content-Type: text/plain;charset="GB2312"
Reply-To: [email-masked]
Date: Wed, 18 Dec 2002 10:43:15 +0800
X-Priority: 3
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

---- No: 6381 ÄãºÃ
ÎÒÃÇÊÇÉîÛÚÏã¹éµç×ÓÓÐÏÞ¹«Ë¾
ÎÒÃÇÌá¹©ÍøÂçÉãÏñ»ú¼°¼à¿ØÏµÍ³µÄ°²×°µ÷ÊÔ
ÍøÂçÉãÏñ»ú×÷ÎªÏÂÒ»´úÉÌÒµÓ¦ÓÃ³ÌÐòµÄ³¬¼¶Æ½Ì¨£¬Ëü¶¼Îª Web ×¨ÒµÈËÊ¿Ìá¹©ÁËÇ°ËùÎ´ÓÐµÄ¹¦ÄÜ¡£
Îª¹ÜÀíÆóÒµÓ¦ÓÃ³ÌÐòÌá¹©ÁËÔËÐÐÊ±¼ä»·¾³ºÍÍ¼Ê¾¹ÜÀí¹¤¾ß¡£
ÈçÓÐÐèÒªÇëÓë¹ãÖÝ°ìÊÂ´¦ÁªÏµ¡¡
µç»°£º020£82349026
ÕÔÇÉ»Ô
¹«Ë¾ÍøÖ·www.xianggui.com
ÓÊ¼þ£[email-masked]

Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBH4k2N27731 for ietf-smime-bks; Mon, 16 Dec 2002 20:46:02 -0800 (PST)
Received: from mail1.ics.ntts.co.jp (mail1.ics.ntts.co.jp [202.32.24.45]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBH4k1o27726 for ; Mon, 16 Dec 2002 20:46:01 -0800 (PST)
Received: from mail26.silk.ntts.co.jp by mail1.ics.ntts.co.jp (8.9.3/3.7W-NTTSOFT-SUR2.0) id NAA16090 for ; Tue, 17 Dec 2002 13:46:00 +0900 (JST) (envelope-from [email-masked])
Received: from helene.mc.ntts.co.jp by mail26.silk.ntts.co.jp (8.11.6/3.7W-silk-4.6) id gBH4jxW24960; Tue, 17 Dec 2002 13:45:59 +0900 (JST) (envelope-from [email-masked])
Received: from [10.7.120.83] ([10.7.120.83]) by helene.mc.ntts.co.jp (8.12.5/8.12.5) with ESMTP id gBH4jwQ7085941; Tue, 17 Dec 2002 13:45:58 +0900 (JST) (envelope-from [email-masked])
Date: Tue, 17 Dec 2002 13:45:58 +0900
From: KATO Akihiro
To: [email-masked]
Subject: Re: Comments on draft-ietf-smime-camellia
Cc: [email-masked]
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-Id: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.05.01
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Hi Jim

On Wed, 20 Nov 2002 13:51:19 -0500
"Jim Schaad" wrote:

snip

> 7. Section 2.2: I strongly suggest that you change the parameters for
> the key wrap algorithm OIDs to be ABSENT rather than NULL.

How is ABSENT that you say the meaning that says? We are using the word
called NULL is 'the parameter does not exist,but parameter field exist'.

I think that this one is good. It is because it becomes clear that the
parameter does not exist.

On the other hand, there is the possibility that is interpreted that
default is used, if place itself that designates the parameter is absent.

Regards.
--
- KATO Akihiro
+ NTT Software Corporation
+ Internet Technology Laboratory

Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBEHDBI09306 for ietf-smime-bks; Sat, 14 Dec 2002 09:13:11 -0800 (PST)
Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBEHD8E09297; Sat, 14 Dec 2002 09:13:08 -0800 (PST)
Received: from arport (h140n2fls31o1122.telia.com [212.181.142.140]) by mailg.telia.com (8.12.5/8.12.5) with SMTP id gBEHCxC3008323; Sat, 14 Dec 2002 18:12:59 +0100 (CET)
X-Original-Recipient: [email-masked]
Message-ID: <003301c2a392$e4d37050$0500a8c0@arport>
From: "Anders Rundgren"
To: "Peter Gutmann" ,
Cc:
References: <[email-masked]>
Subject: Re: e-Government uses "Authority-stamp-signatures"
Date: Sat, 14 Dec 2002 18:04:39 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Peter,

Late-breaking news received off-list! Apparently the Estonian
(http://www.cyber.ee/infosecurity/projects/xroad-pilt.html )
and Italian e-Governments are also working along similar lines
as their Swedish counterpart. Everybody seems wanting to get
credit for being a part of the paradigm-shift! Who's next? :-)

now to the technicalities....

As you probably have noted, technologies for server-based secure
messaging are currently in a state of extreme flux, so all efforts
are likely to be more or less "home-brewed". Or built on s.c.
"standards" that are obsoleted a year or two after being intro-
duced which is about the same thing. :-(

I believe that DOMSEC has unfortunately already met its maker.
Even SMTP and S/MIME will diminish in importance due to the
"Web Services" craze. The practically "frictionless" [transport]
encryption offered by HTTPS as well as the support for synchronous
operation are absolutely crucial in many scenarios. SMTP will
in the O2O context probably be "degraded" to a user-notification-
tool for otherwise Web Services-based messaging and work-flow.

Long-term all these systems will probably (hopefully?) converge into
"true" Web Services using WS-Security and XML Signatures.

cheers
Anders R

----- Original Message -----
From: "Peter Gutmann"
To: ;
Cc:
Sent: Saturday, December 14, 2002 03:45
Subject: Re: e-Government uses "Authority-stamp-signatures"

[CC'd across to ietf-smime]

"Anders Rundgren" writes:

>It may be interesting to know that Swedish authorities are currently
>launching a Web Services-like system called SHS, where authorities
>communicate with each other through web-server "nodes" where out-going
>messages are automatically signed by the authority identified as an "entity"
>(organization), rather by an individual associated to the authority.

Does this follow a particular model like DOMSEC, or is it yet another roll-
your-own? There appear to be a number of groups doing DOMSEC-like things, but
everyone's doing it differently...

Peter.

Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBE35jD06825 for ietf-smime-bks; Fri, 13 Dec 2002 19:05:45 -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.3) with ESMTP id gBE2jJE05349; Fri, 13 Dec 2002 18:45:20 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id gBE2jGbT018183; Sat, 14 Dec 2002 15:45:16 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id gBE2jGc07400; Sat, 14 Dec 2002 15:45:16 +1300
Date: Sat, 14 Dec 2002 15:45:16 +1300
Message-Id: <[email-masked]>
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: e-Government uses "Authority-stamp-signatures"
Cc: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

[CC'd across to ietf-smime]

"Anders Rundgren" writes:

>It may be interesting to know that Swedish authorities are currently
>launching a Web Services-like system called SHS, where authorities
>communicate with each other through web-server "nodes" where out-going
>messages are automatically signed by the authority identified as an "entity"
>(organization), rather by an individual associated to the authority.

Does this follow a particular model like DOMSEC, or is it yet another roll-
your-own? There appear to be a number of groups doing DOMSEC-like things, but
everyone's doing it differently...

Peter.

Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB942EY10934 for ietf-smime-bks; Sun, 8 Dec 2002 20:02:14 -0800 (PST)
Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB942Cg10930 for ; Sun, 8 Dec 2002 20:02:12 -0800 (PST)
Received: from revelation (12-230-156-246.client.attbi.com[12.230.156.246]) by sccrmhc02.attbi.com (sccrmhc02) with SMTP id <2002120904015400200fh2jke>; Mon, 9 Dec 2002 04:01:54 +0000
Reply-To:
From: "Jim Schaad"
To: "'Peter Gutmann'" ,
Subject: RE: Draft Minutes
Date: Sun, 8 Dec 2002 20:01:30 -0800
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To:
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Peter,

Yes, I would consider that to be sufficent. I have not read your code
dealing with this issue. Many of the versions I know about do a full
decode of the structure and would fail decode if new structures were
added.

jim

> -----Original Message-----
> From: Peter Gutmann [mailto:[email-masked]]
> Sent: Sunday, December 08, 2002 7:43 PM
> To: [email-masked]; [email-masked]
> Subject: Re: Draft Minutes
>
>
> [Apologies if you've seen this before, one of our machines
> has been quietly
> dropping outgoing mail...]
>
> "Jim Schaad" writes:
>
> >There was a discussion dealing with two issues found during
> interoperability
> >testing. The first dealt with the fact that so far no
> implementations are
> >known that deal gracefully with unknown RecipientInfo and SignerInfo
> >structures.
>
> What's the definition of "deal gracefully"? When this was
> discussed quite
> some time ago, I modified my code to ignore new structures
> that it didn't
> recognise, and I thought there were indications from others
> that they would be
> doing the same. Is that sufficient?
>
> Peter.
>
>

Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB93gfo10297 for ietf-smime-bks; Sun, 8 Dec 2002 19:42:41 -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.3) with ESMTP id gB93gcg10291 for ; Sun, 8 Dec 2002 19:42:38 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id gB93gZxI031950 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 9 Dec 2002 16:42:36 +1300
Date: Mon, 9 Dec 2002 16:42:36 +1300 (NZDT)
From: Peter Gutmann
To: [email-masked],
Subject: Re: Draft Minutes
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

[Apologies if you've seen this before, one of our machines has been quietly
dropping outgoing mail...]

"Jim Schaad" writes:

>There was a discussion dealing with two issues found during interoperability
>testing. The first dealt with the fact that so far no implementations are
>known that deal gracefully with unknown RecipientInfo and SignerInfo
>structures.

What's the definition of "deal gracefully"? When this was discussed quite
some time ago, I modified my code to ignore new structures that it didn't
recognise, and I thought there were indications from others that they would be
doing the same. Is that sufficient?

Peter.

Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB6LwdJ04081 for ietf-smime-bks; Fri, 6 Dec 2002 13:58:39 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id gB6LwZg04076 for ; Fri, 6 Dec 2002 13:58:36 -0800 (PST)
Received: (qmail 19844 invoked from network); 6 Dec 2002 21:58:26 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.181.81) by woodstock.binhost.com with SMTP; 6 Dec 2002 21:58:26 -0000
Message-Id: <[email-masked]>
X-Sender: [email-masked] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Fri, 06 Dec 2002 16:58:16 -0500
To: [email-masked]
From: Russ Housley
Subject: Re: Draft Minutes
In-Reply-To:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

If anyone has comments on the minutes that were posted by Jim Schaad,
please send a message to the list by Tuesday, 10 December. The Minutes are
due to the IETF Secretariat soon.

Thanks,
Russ

Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB6L0tG28685 for ietf-smime-bks; Fri, 6 Dec 2002 13:00:55 -0800 (PST)
Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB6L0ng28661 for ; Fri, 6 Dec 2002 13:00:49 -0800 (PST)
Received: from revelation (12-230-156-246.client.attbi.com[12.230.156.246]) by rwcrmhc52.attbi.com (rwcrmhc52) with SMTP id <20021206210045052001ajs1e>; Fri, 6 Dec 2002 21:00:45 +0000
Reply-To:
From: "Jim Schaad"
To:
Subject: Draft Minutes
Date: Fri, 6 Dec 2002 13:00:27 -0800
Message-ID:
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0014_01C29D27.72F09510"
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
X-MS-TNEF-Correlator: 00000000C61F957EEEE3D311963C000086335A64E42A2900
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

------=_NextPart_000_0014_01C29D27.72F09510
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Here are the minutes for the working group meeting in Atlanta.

Minutes for the S/MIME Meeting
IETF 55
November 19, 2002

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 3369 - Cryptographic Message Syntax
- RFC 3370 - Cryptographic Message Syntax (CMS) Algorithms
- RFC 3394 - Advanced Encryption Standard (AES) Key Wrap Algorithm

RFC Editors Queue:
- There are currently no documents in the RFC Editor Queue

IESG
- CMS Symmetric Key Management and Distribution
- 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

Examples Draft: Paul Hoffman was unable to be present so Russ presented =
for
him. There has been a recent discussion on the list that a triple-wrap
example as defined in ESS (RFC 2634) should be added to the draft. John
Pawling has volunteered to provide this example. After it is =
incorporated
the document, and a few minor edits are made, the Examples Draft should =
be
ready for working group last call.

X400 Transport and Wrap Drafts: Chris Bonatti gave the presentation for
these two drafts. There were some comments from the IESG on the =
documents,
and some synchronization between the RFC2633bis Draft and X.400 Wrap =
Draft
was needed. The IESG comments have been resolved, and the two S/MIME
working documents are now consistent. The X.400 Transport and Wrap =
Drafts
are ready for the IESG. Chris is trying to coordinate a review of the
documents by the ITU-T group responsible for X.400, but this should not =
stop
the draft from going to Proposed Standard. Any comments from this group =
can
be incorporated before going to Draft Standard.

AES Algorithm Draft: Jim Schaad stated that the document has been =
modified
to remove the requirement that AES is not to be used with PKCS #1 v1.5. =
The
document will be submitted as soon as the repository opens, and then the
chair will make the working group last call.

CMS Interoperability Status: Jim Schaad stated that advancement has =
been
made since the last meeting for CMS interoperability. There are 6 test
cases left to complete interoperability testing. These test cases deal
with: 1) v2 attribute certificates for SignedData and EnvelopedData; 2)
unrecognized SignerInfo structures; 3) unrecognized RecipientInfo
structures; and 4) version numbering in EnvelopedData for pwri and/or =
ori
being present as a RecipientInfo. The v2 attribute certificate test =
cases
should be finished soon as a bug is found and fixed in one =
implementation.

There was a discussion dealing with two issues found during =
interoperability
testing. The first dealt with the fact that so far no implementations =
are
known that deal gracefully with unknown RecipientInfo and SignerInfo
structures. No discussion was generated from the floor. The second =
issue
dealt with the fact that there is no MUST statement on handling of =
detached
as opposed to embedded content. Both detached content and embedded =
content
are mandated by the S/MIME message specification (RFC 2633) for =
SignedData,
and embedded content is mandated for EncryptedData. Should this be =
moved
into the CMS draft as well? No discussion from the floor ensued.

Camellia Draft: KATO Akihiro gave the presentation on the draft for =
Camellia
to be used as a content encryption algorithm with CMS. Camellia =
operations
at the same block and key sizes as AES. Camellia will use the AES key =
wrap
algorithm for doing key encryption. The authors are going to be adding =
a
section on SMIMECapabilities before the next revision. Information on
Camellia can be gotten at http//info.isl.ntt.co.jp/camellia.

Message Update Draft: Blake Ramsdell was unable to make it to the =
meeting.
Russ presented Blake's slides for him. The current draft was modified =
to
deal with allowing for binary transport internally, signing message =
headers
and using the compression content type. Following the presentation the
chair stated that the document should be ready to progress and a last =
call
will be issued shortly.

Certificate Update Draft: Russ also presented the certificate draft =
updates
for Blake. The changes in the last draft are changes to the wording for
email address matching and to deal with the =
nonRepudiation/digitalSignature
bits in the key usage certificate extension. There are still some
additional changes are needed to resolve previously submitted comments.
Also, there are some TBA areas in the draft.

IESG status of HMAC Key Wrap draft: Jeff Schiller was asked to give =
further
information about the current status of the HMAC Key Wrap draft which is
currently stuck at the IESG. The issue has to do with the fact that the
working group requested publication as an Informational RFC, which for
advancement purposes is really below Proposed Standard for purposes of
advancement. Thus any document that relied on it could not go forward.
Russ said that this has been historically what has been done by this =
working
group; document describing algorithms are informational, while documents
describing how to use the algorithms are standards track. Jeff is going =
to
attempt to get the problem solved on a basic level, however the working
group granted permission to move the document to standards track if it
appears that solving the basic problem is going to take too long.

------=_NextPart_000_0014_01C29D27.72F09510
Content-Type: application/ms-tnef;
name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="winmail.dat"

eJ8+IhsVAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGAAcAAQAAAAAAAAEGgAMADgAAANIHDAAG
AA0AAAAAAAUA/QABA5AGAMwPAAApAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAAC
ATEAAQAAABgAAAAAAAAAxh+Vfu7j0xGWPAAAhjNaZKQqKQADADYAAAAAAB4AcAABAAAADgAAAERy
YWZ0IE1pbnV0ZXMAAAACAXEAAQAAABYAAAABwp1qaMJEWvHL41FBGJRAFfeeEKuVAAACAR0MAQAA
ABcAAABTTVRQOkpJTVNDSEBOV0xJTksuQ09NAAALAAEOAAAAAEAABg4ASIpwap3CAQIBCg4BAAAA
GAAAAAAAAADGH5V+7uPTEZY8AACGM1pkwoAAAAMAFA4AAAAACwAfDgEAAAACAQkQAQAAAMwLAADI
CwAAqBcAAExaRnWe+rReAwAKAHJjcGcxMjXiMgNDdGV4BUEBAwH3/wqAAqQD5AcTAoAP8wBQBFY/
CFUHshElDlEDAQIAY2jhCsBzZXQyBgAGwxEl9jMERhO3MBIsETMI7wn3tjsYHw4wNREiDGBjAFAz
CwkBZDM2FlALpiBImQSQZSAKwB0gdGgdIPptC4B1DrAEIAIQBcAdgsp3BbBrC4BnIAnACGB2cB2w
CeB0HwILgBDAdHMLYAIwYS4KogqEIRZNgR3dUy9NSU1FBdCDH7Qg1ElFVEYgGmBhINROb3ZlBtAS
gTFoOSwgAdAwDlAg6UFCZwnwZGE6IAfwdQUEEUgIYHNsZXkg7wWgJSAYIR1zYSbjHjcfpX4uJ0Al
ACggE+AfEAeRd68dAgDAAQAgy1ce1UcfU7pTAZB0J3AnPyhJcy2DaCBvZiikYx/QJSAg8GRvY3UH
gAIwBCAgIXsejypRVB2RMOgdgC2QID8T4DCxKrQokC+VAJBuY18dZAtgL5Aflx1BOiDaUP51AmAE
AB2QKJA2EB0wA6AoUkZDNwUtOMIgM4kcIDkgOXBDcnkFMOJvCcBhcGgN4CNRBBDXKPEUUSCReDkc
NxZQOi9ROzsgKEMF4CkQwGxKZwWwaR2AbXM5HDniND0BQWR2AHA1kCiQ9kU1gD1CaQIgLWInAQsg
qT7wQUU/MUsoAVc9oec/WCDaOZJFZD+wBbAEIH5RClAKUDkHMvEdFTEAcusYIAIwbCgQbiqQMO9F
SOdF9CDaJDBTRzkWPxEUUt0HgHQFEDsAQ2JNAHAo8bcxIjiRKJBEBABMcWId8JtCMTkWVRQQL/ZS
U0MRdC1PQxBQMuA9oACAcP8XwT9YIBI/EUZnUKYfAiL1GE9iagWQMVRYLjT/JeA5FgZgR4EfAlSj
EiECML9NcgPwHYAi5TkWQ6JwNpPRA6BITUE5sGsoAVbjzylAUJAFICfwLURDIENTHwWxA5FDEUNS
INpFeGF2bVoBBCBEPaABgC3RULxhdQMgLlABIAOCdzhxPnVNIAJgHWEqkCVQIHD3GCAUEE2BcyqQ
LgNfRSiB+x5CPdBtMsQdERPgBCAlUP8J8FmhGCA1kE2BRZAE8C4R/0IyQkE1w04BM8QpQExxWgL+
d0OyDsBcczhiAQELgCiBFyAhQyAF8Cg5kjI2M+40P0A4IAhgbCiQXxErkG8BACiRKpAdgmRc8ipR
SuxvaAOgXWB3OAAfEWHi/nYG8F5wDrAoZCqQX0AlEL5pAQAdcQQAZZYqUUEBgP8SgT+wIBAxYgWh
UOEtkCiF/0hWJbBNsilBB9EdwQWxCYD/P7A4gStVJbAdglxcZ+kYIF8rkCgQHkIezDYDYwdAbP0g
y1hWIlCYTbJDo1zjLcLsQ2gFEAQgQgIgLZAf0P8fMDQyHYJfRS2QQjIeRU9B9nQewGlUc2FXKzNf
wAeA/yghTEExQgNSHXNLImOmSFd7b6R843M7sBPQA2ADAHo/emQlUHtgYjJJJWeRM2L/bIFylE2y
VgR3qF4jZpAJgP8JgDLFflN9NzQjYiNfUQbw/SUgZG+kHYJ7YiL1HsZIWP8dQkggB+AFoACBL5Ax
MTLF/1YEds931h0zc5h+FipReIT7bIFMcHkfAl7hBaAFsEWQf3kBHSFigWwQB9EwBUhYYsMoEH4T
VFUtVB81X1H/UOAAgV6iHkJUoyWwTlFsVP9n9UggX6E9cB+AaSd9tD+A/Y/VUANgUOAUECiQQnZt
Iv5uKBJ9XGyBH0R1YIEybgz/JVAeQR0gl7dylJjXJhtaUftROFzmSgdwBgAT0SuQL4P/KIMz8W7q
YdgEYQaQCJBo048YIARgeYUYIHF1aaQx/01yM9NbImyBljJe5C4QKIGRVuNQS0MF8CMxauB4MS41
Ms1W0XWAXwJz/zfgHcACQDhEX8BCQThxpKT3mHFFolqhcAnwf5UdgTGU/xPRpSCpVADAWSAxr3T/
ISX9S+JJVoGYUQSQAaADED+w/ygQLXegr2RlQUSinSuRNV9/H7UeQkviC4CxTGFXHUI2/x1wB5Cv
shQQBCAn8HLBkBP/XIKQwbfOuaMqJDLxezK5yK8BAAdAVtMt0DE/QHYUQP95EU4zNFEEkB/QZnCv
0B4G6FNpZ2aRRC2QKUBNst9BwCUgF7CsMMFDOyXAP0C/XnBikT2AgMGYosECcrEgewIQL4FyGtAt
oF9RwrAz/cLtUgWQBSAIkAIwxD9Nsv9nwShRY2Md4CVCH+XB6x4z7nBlUHlAQpEvBbE/kV8B/x8C
X0Y4csY8MsW/H8Aluar/Z/hmcTgUqrYpQE5QIAEeIu9ecDhRTcFmcHhmpAIgm6H/XIIxInpjIMt8
NcyjYwm+Mr8fAlbje2IEAQpQ0pZkVaT/u3+8i9EBFABi4b5BVsUdgv5mMHEzxF/B3NAFwEgh1Cz9
cQRrijExkjPxvjM9kbYA/mZdgEfxVuNecN9UxkxNsv/D38TiKlRjCV4yJuGxkWCj/X3WZhewBbAy
xRQQinFmsX/YYtvf3OcdgR0RpjMF0FW+U5NAoVNNY0JBKsFkamP/MAEBAAGQE9A4RJaQmHRe4f8l
MmijinGK1XjgVwHsh+6F/02j7f5xFScBnFOSpCL1B4H/O1NQ0MZRwDNCMmdGxUHAvP9vpPDPbIHy
Fx5CQcXBNCpR/lNoBGxjXxGkUmayaPVL4u+XBDhxKzB1gD/kXuY8ZZD3AIAKUJ5sQ1xw/KEHMFzW
8EtBVE8QwB7wPdADYP95X3pkfqaXFLdSABamqcyj//AGCfBB59dgUVanUz8RjuL/ABaxc961ofQ7
UH0BF/Aw8P5rTaNZIpQgw5DMsRCxQyD/CCqpY6cBHXNbIlkjQ7IHCP+3QkhQHwJZIgZYMsVdcKdw
f0XCuVKXt2hkNpPncgLmU/8jEgAAGxCxw5FAYgKcsx2CfWaQeGSgkRJjYipRxtJy/7WAAuYAB5tV
P4CqMWJRNAHxqjBwLy+QkM2h5/B1kOcgkGmgm+Auahkwr9AAJLMgyzsmVXDyQlzXQiBw9a4xUlxw
c2ZQqYFePK4T322xaPUp6F/9HVMnNUE4AP9mUMCUYSdHdpb11jKjer43/wbxwiCnULcVgoBNIKvx
THD/ULa3w00g4MFvoJQgw2EyQf/zhhVAK5ERMk3BLhCP060yf7rxX1FjY/AGsgD0EORBRv9rACYV
Ai+tKKFfomZy/mu0/5rwOzFvta+HqVfn83/hERH/R+GwHM8ZHG0gs9dgX8FgSP+tI88ZlwSTkPJC
wJQdUyMG/+vB5ZBI16+D/AVHUjtVaPX/rqESg7dCTVCtgKmQaJEx838WwezAWGQlDRUz9LDGQHDW
dUWQemMvRZBnFGDXYP/A8rJRR1GCgEjIWSIgwBwi/88KFYGsQRBHuSW8oamBfOP/EmL0kr5RO0aJ
84TDo/SHI/9fMmwQk4AiIAsRqfd9Nm0ijzeBcaNGpnzyVEJBEVL/C5FD5Wlk1Rp+Uy7yIMCRct9Y
01qCg8NpYx0gSmZgkZDvswGpcW2B1jNzWSBo00Kg/wHx4KDPIGGRZsEWmLGwk4D/ofQjdlAoFTJQ
z4RCItDswP9t0iN1StKyYAqCofSOpdtC/+f0YeIlIrrA6L+h9K6spOL/ucEhcUHglED0ZsyiYlAW
ef++UfTxb6BYlLdCtDpB4G5R/7oibIGNweDCaGAmEZg/+IT/YueRgbQ52xNQYYwAshCiV//dI6Uw
FFAhcfSxbbGb4JX2/xhgerLWMJkzILMcECJAL1b/0oG095qxq9E10eDD3TK09/9/ENPxkpPSga6r
wrCiVyJR//kAlDASk5+WSNRUmddgYWP/HsGJWHD5ERCKUATRDQZxre8u8ZkDj4LgcGvkQVITmsJ/
l8bOYbSQ+TBTg+yQLTVv/5RBffCHJH6S0iELkDXQulH/wgH2cHUxfCGORK6s4FEhU/+xgaoQ5PQe
8qRmaAjEYnc7/8lgeGG0Ee1QKaAp4d0lh0D/KnZ7tHp2eIrsoK4y0bC2YC/0sCBw1Rqe5H2HcAMA
khADAAAAAgEUOgEAAAAQAAAAtkHF2RbBXkKhaMYtTWXXhgMA3j+fTgAAAwAJWQEAAAADAEBlAAAA
AAMAAIAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwADgAggBgAAAAAAwAAAAAAAAEYAAAAA
UoUAAOOQAQAeAASACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAUAAAAxMC4wAAAAAAsABYAI
IAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwAGgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAA
AAALAAeACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAsACIAIIAYAAAAAAMAAAAAAAABGAAAA
AA6FAAAAAAAAAwAKgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAALABaACCAGAAAAAADAAAAA
AAAARgAAAACChQAAAQAAAAIB+A8BAAAAEAAAAMYflX7u49MRljwAAIYzWmQCAfoPAQAAABAAAADG
H5V+7uPTEZY8AACGM1pkAgH7DwEAAABJAAAAAAAAADihuxAF5RAaobsIACsqVsIAAG1zcHN0LmRs
bAAAAAAATklUQfm/uAEAqgA32W4AAABDOlxtYWlsXGN1cnJlbnQucHN0AAAAAAMA/g8FAAAAAwAN
NP03AgACARQ0AQAAABAAAABOSVRB+b+4AQCqADfZbgAAAgF/AAEAAAAxAAAAMDAwMDAwMDBDNjFG
OTU3RUVFRTNEMzExOTYzQzAwMDA4NjMzNUE2NEU0MkEyOTAwAAAAAAMABhAdZhdnAwAHENARAAAD
ABAQAAAAAAMAERABAAAAHgAIEAEAAABlAAAASEVSRUFSRVRIRU1JTlVURVNGT1JUSEVXT1JLSU5H
R1JPVVBNRUVUSU5HSU5BVExBTlRBTUlOVVRFU0ZPUlRIRVMvTUlNRU1FRVRJTkdJRVRGNTVOT1ZF
TUJFUjE5LDIwMDJBRwAAAAC4fw==

------=_NextPart_000_0014_01C29D27.72F09510--

Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB5KiUj01995 for ietf-smime-bks; Thu, 5 Dec 2002 12:44:30 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB5KiSg01983 for ; Thu, 5 Dec 2002 12:44:28 -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 PAA27496; Thu, 5 Dec 2002 15:41:38 -0500 (EST)
Message-Id: <[email-masked]>
To: IETF-Announce: ;
Cc: [email-masked]
From: The IESG
SUBJECT: Last Call: Use of the RSAES-OAEP Transport Algorithm in CMS to Proposed Standard
Reply-to: [email-masked]
Date: Thu, 05 Dec 2002 15:41:38 -0500
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

The IESG has received a request from the S/MIME Mail Security Working
Group to consider Use of the RSAES-OAEP Transport Algorithm in CMS
as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2002-12-19.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-rsaes-oaep-07.txt

Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB4Jf7D19319 for ietf-smime-bks; Wed, 4 Dec 2002 11:41:07 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id gB4Jedg19314 for ; Wed, 4 Dec 2002 11:40:39 -0800 (PST)
Received: (qmail 28323 invoked from network); 4 Dec 2002 19:40:32 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (208.208.101.17) by woodstock.binhost.com with SMTP; 4 Dec 2002 19:40:32 -0000
Message-Id: <[email-masked]>
X-Sender: [email-masked] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 04 Dec 2002 14:40:08 -0500
To: "Dieter Bratko" ,
From: Russ Housley
Subject: Re: SignedReceipt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

"Dieter:

It simply needs to be a unique identifier of the signed content. This
allows the originator of the original message to locate the message when
the receipt arrives.

Russ

At 04:02 PM 11/28/2002 +0100, Dieter Bratko wrote:

>Hello,
>
>Implementing the ESS Signed Receipt service I would like to tell the
>following question regarding the role of the message originator:
>According to RFC2634 the signedContentIdentifier field should contain
>user-specific identification information (such as a user name or public
>keying material identification information). When creating a receipt the
>signedContentIdentifier is copied from the receiptRequest to the receipt:
>
>Receipt ::= SEQUENCE {
> version ESSVersion,
> contentType ContentType,
> signedContentIdentifier ContentIdentifier,
> originatorSignatureValue OCTET STRING }
>
>
>
>Is my interpretation right that the user-specific identification information
>implicitly contained in the signedContentIdentifier -- since it has to be
>the same for any receiptRequest attribute of any SignerInfo containing a
>receiptRequest attribute -- refers to the (one and only) message originator
>(sender), but the originatorSignatureValue field holds the signature value
>from the SignerInfo just processed (which not necessarily has to be the
>signerInfo of the originator); and when creating the receipt it does not
>mind which SignerInfo it is based on (the validator must be able to validate
>receipts based on any SignerInfo contained in the original SignedData)?
>
>Regards,
>Dieter Bratko
>
>---------
>Dieter Bratko,
>Institute for Applied Information Processing and Communications (IAIK)
>Graz University of Technology, Inffeldgasse 16a, 8010 Graz, Austria,
>http://jce.iaik.tugraz.at/

Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB4CdWq17901 for ietf-smime-bks; Wed, 4 Dec 2002 04:39:32 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB4CdTg17895 for ; Wed, 4 Dec 2002 04:39:30 -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 HAA07942; Wed, 4 Dec 2002 07:36:39 -0500 (EST)
Message-Id: <[email-masked]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cms-rsaes-oaep-07.txt
Date: Wed, 04 Dec 2002 07:36:38 -0500
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--NextPart

Title : Use of the RSAES-OAEP Transport Algorithm in CMS
Author(s) : R. Housley
Filename : draft-ietf-smime-cms-rsaes-oaep-07.txt
Pages : 15
Date : 2002-12-3

This document describes the conventions for using the RSAES-OAEP key
transport algorithm with the Cryptographic Message Syntax (CMS). The
CMS specifies the enveloped-data content type, which consists of an
encrypted content and encrypted content-encryption keys for one or
more recipients. The RSAES-OAEP key transport algorithm can be used
to encrypt content-encryption keys for intended recipients.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-rsaes-oaep-07.txt

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

Send a message to:
[email-masked].
In the body type:
"FILE /internet-drafts/draft-ietf-smime-cms-rsaes-oaep-07.txt".

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

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

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cms-rsaes-oaep-07.txt

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

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--