MIME Parser needed

[Guangsheng Liu <[e-mail]>]

Currently, I am developing a email reader. Does any body know there is a 
MIME parser in the market?
Thanks.




Received: by ns.secondary.com (8.9.3/8.9.3) id DAA00131 for ietf-smime-bks; Fri, 30 Jun 2000 03:41:56 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA00127 for <[e-mail]>; Fri, 30 Jun 2000 03:41:54 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12659; Fri, 30 Jun 2000 06:42:46 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>
Cc: [e-mail]
From: The IESG <[e-mail]>
Subject: Document Action: Use of the IDEA Encryption Algorithm in CMS to Informational
Date: Fri, 30 Jun 2000 06:42:46 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the Internet-Draft 'Use of the IDEA Encryption
Algorithm in CMS' <draft-ietf-smime-idea-05.txt> as a Informational
RFC.  This document is the product of the S/MIME Mail Security Working
Group.  The IESG contact persons are Jeffrey Schiller and Marcus
Leech.


Note to RFC Editor:

Please be sure to insert the IPR text from RFC2026 prior to publication.





Received: by ns.secondary.com (8.9.3/8.9.3) id LAA26763 for ietf-smime-bks; Thu, 29 Jun 2000 11:25:34 -0700 (PDT)
Received: from gem.lightlink.com ([e-mail] [205.232.34.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26759 for <[e-mail]>; Thu, 29 Jun 2000 11:25:32 -0700 (PDT)
Received: from kermit.eloq.com (ith2-7a3.twcny.rr.com [24.24.16.163]) by gem.lightlink.com (8.8.8/8.8.8) with ESMTP id OAA25680 for <[e-mail]>; Thu, 29 Jun 2000 14:26:07 -0400
Message-Id: <4.3.1.0.20000629143025.00a7e490@192.9.200.22>
X-Sender: gliu#pop.lightlink.com@192.9.200.22
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 29 Jun 2000 14:33:11 -0700
To: [e-mail]
From: Guangsheng Liu <[e-mail]>
Subject: what is "Content-Disposition" field?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,
   Many thanks for some of you recomending MIME++ parser from 
http://www.hunnysoft.com/.
I have another question, what is the purpose of "Content-Disposition" 
field, I checked RFC822 and RFC2045-2049, cannot get the answer.

   Guangsheng Liu



Received: by ns.secondary.com (8.9.3/8.9.3) id FAA29072 for ietf-smime-bks; Wed, 28 Jun 2000 05:37:00 -0700 (PDT)
Received: from exch-bhs-2.redstone.army.mil (exch-bhs-2.redstone.army.mil [136.205.13.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA29067 for <[e-mail]>; Wed, 28 Jun 2000 05:36:59 -0700 (PDT)
Received: by exch-bhs-2.redstone.army.mil with Internet Mail Service (5.5.2448.0) id <NH8FHDS0>; Wed, 28 Jun 2000 07:37:58 -0500
Message-ID: <1345B59AC3C5D211975E00A0C99DAC7A0128E07F@exch-msg-6>
From: "Nord, John D Contractor/NCCIM" <[e-mail]>
To: "'Guangsheng Liu'" <[e-mail]>
Cc: [e-mail]
Subject: RE: MIME Parser needed
Date: Wed, 28 Jun 2000 07:37:47 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Check out MIME++ at http://hunnysoft.com/mimepp/.

-----Original Message-----
From: Guangsheng Liu [mailto:[e-mail]]
Sent: Tuesday, June 27, 2000 6:10 PM
To: [e-mail]
Subject: MIME Parser needed


Currently, I am developing a email reader. Does any body know there is a 
MIME parser in the market?
Thanks.


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA10452 for ietf-smime-bks; Tue, 27 Jun 2000 21:43:54 -0700 (PDT)
Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA10446 for <[e-mail]>; Tue, 27 Jun 2000 21:43:53 -0700 (PDT)
Received: from nwlink.com (listserv.nwlink.com [209.20.130.70]) by smtp.nwlink.com (8.9.3/8.9.3) with SMTP id VAA25214; Tue, 27 Jun 2000 21:44:29 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
Reply-to: [e-mail]
To: [e-mail];[e-mail];;;
Cc: [e-mail]
Date: Tue, 27 Jun 2000 21:44:29 +0800
Subject: Comments on draft-ietf-smime-domsec-05.txt
Message-id: <[e-mail]>
X-User-Info: 4.54.168.248
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

1.  Should the X.400 on hetrogenous messaging be expanded to X.400/P1 similar
to SMTP/MIME

2. Section 1.0 bullet 4:  Should be Heterogeneous Message Formats not transports.
 The problem is if you cannot carry the S/MIME content type not the wrapper
on the message. (Microsoft Exchange actually uses X.400 headers with a custom
content type for internal replication last time I checked and this did not break
signatures on these messages as the MIME structure was carried intact.)

3. Section 1 last paragraph: change to more standard wording on MUST.

4. Section 2.1 formatting problem: "signature(if present)using" goes to "signature
(if present) using"

5. Section 2.2 - remove MAY from the last sentence.  This is a reason to do
the signatures, but is not part of the protocol definition. -- change MAY to
could.

6. Section 2.3 - ditto above comment for first sentence.  You can do this, but
it is not part of the protocol defintion.  change MAY to can.

7. Section 3.0 bullet 1: change "will be id-data" to "MUST be id-data"

8. Section 3.0 bullet 1: This concept bothers me.  I think that there may be
some programs out there that assume atleast one signature in a signed data object
except for cases such as degenerate certs only messages.

9. Section 3.0 bullet 1: A better term for this might be a null (or empty) signature
layer.  This will difference the concept from the discussions about signing
with the NULL signature algorithm.

10. Section 3.0 bullet 2: This not clear about the presence (or absense) of
a MIME layer.  If MIME layer exists, then I fail to see the need for bullet
1 at all.

11. Section 3.0 Para 1:  Simple example of why counter-signature and parallel
signatures do or don't work for this might be called for.

12. Section 3.1.1 Paragraph 5 - Apears to imply that cn="Jim Schaad - review-authority"
is legal (difference between 'in' and 'as'.  Additionally you might want to
do capitalization here as utf8 strings do not do case insensitive name compararisions
(i.e. Review-Authority).  Also is cn="Jim Schaad" cn="review-authority" legal?
[By definition I think that this would only need to be done if the review was
on the innermost signature layer.  On outer layers I don't believe the intent
was that name checking of the certificate and sender should occur otherwise
signing MLAs will create lots of havoc.]

13. Section 3.1.1 Paragraphy ? - Should "domain-signing-authority@com" be explicity
forbidden?

14. Section 3.1.1 Last Paragraphy - Please soften last sentence.  The correct
action should be to flag sender/certificate mismatch not to reject as invalid.


15. Section 3.1.2 Paragraph 4 - Please tell me where [CMS] provides a description
of generating and processing siganture types.  I believe that you meant "All
signatures are processed..."

16. Section 3.1.2 Paragraph ~5 - Please put text in to OID definition using
the -- comment syntax of ASN.  i.e.
	id-aa-sigtype-domain-signature :: OBJECT ID {....}
		-- Domain Signature

17. Section 3.1.2 Paragraphy last - 3 - Please remove or refine text about originator
signature not ecapuslating other signatures -- you are eleminating triple wrapped
signature from existance (i.e. S2(E(S1(M))) where S1 and S2 are by the originator.
 

18. Section 3.1.2 Paragraph last-2 - Can different SignerInfos at the same level
have different content in the SigantureType attribute or not?

19. Section 3.2 Paragraph 4 - If this siganture is to be kept around, you must
remove the mlaExpansion or the first MLA outside will strip the domain signature
from the message.

20. Section 3.2 Paragarph 11 - Why is this only a MAY.  It would appear that
the correct statement is MUST as otherwise the whole process is wasted.

21. Section 3.2 Paragaph  ? - Where and how did you get the FROM address in
the message.  Unless you make a statement about including the SMTP headers at
the time of wrapping all you get is the MIME headers which do not include this
information.  (i.e. this is never going to happen unless you call for it to
happen.)

22. Section 3.2 Last Paragraph - Change to make a statement about a single layer
as well (or instead of).

23. Section 3.3 Paragraph 4 - did you mean to reference ESS not CMS?

24. Section 3.3 Bullet 1 - If I have S1(S2(S3(M))).  S1 has an equivalent label,
S2 and S3 both have labels, and the labels are different.  Is the equivalent
label the same as both labels or only one?

25. Section 3.3 Paragraphy Last-2 - This MAY should be a MUST

26. Section 3.3 Paragarph Last - ditto froms ection 3.3

27. Section 3.5 - By default you can have multiple originator signatures (potentially
with different algorithms) in a message.  So the restriction in this section
makes no sense.

28. Section 4 - Where on this table would you put the case of Originator Encrypts
to Recipient Domain which encrypts to Receipient?  It would appear to be an
instance of (a), (b) and (c).

29. Section 4 Paragraphy Last-2 - How can I possibly enforce this?  For Key
Transport the sender is anonymous, for Key Agreement the senders certificate
is often not examined.  Additionally the domain component could change so that
does match -- or it might be my domain component that did the re-enecryption
and would therefore match my domain name and not the senders domain name.

30. General - Please include ASN.1 module at the end with a list of all defined
OIDs and structures.  Get module oid from Russ.  (This request is just pure
lazyness on my part but makes some things easier.)

31. General - Do we need to specify the big brother syndrome at this time (encrypt
for end-entity and for DCA)?

jim schaad
http://www.nwlink.com


Received: by ns.secondary.com (8.9.3/8.9.3) id NAA25924 for ietf-smime-bks; Tue, 27 Jun 2000 13:02:21 -0700 (PDT)
Received: from gem.lightlink.com ([e-mail] [205.232.34.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA25920 for <[e-mail]>; Tue, 27 Jun 2000 13:02:19 -0700 (PDT)
Received: from kermit.eloq.com (ith2-7a3.twcny.rr.com [24.24.16.163]) by gem.lightlink.com (8.8.8/8.8.8) with ESMTP id QAA10550 for <[e-mail]>; Tue, 27 Jun 2000 16:03:00 -0400
Message-Id: <4.3.1.0.20000627155953.00a79ae0@192.9.200.22>
X-Sender: gliu#pop.lightlink.com@192.9.200.22
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Tue, 27 Jun 2000 16:10:06 -0700
To: [e-mail]
From: Guangsheng Liu <[e-mail]>
Subject: MIME Parser needed
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>

Currently, I am developing a email reader. Does any body know there is a 
MIME parser in the market?
Thanks.



Received: by ns.secondary.com (8.9.3/8.9.3) id GAA07040 for ietf-smime-bks; Tue, 27 Jun 2000 06:09:11 -0700 (PDT)
Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07034 for <[e-mail]>; Tue, 27 Jun 2000 06:09:09 -0700 (PDT)
Received: by balinese.baltimore.ie; id OAA10397; Tue, 27 Jun 2000 14:09:48 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma010383; Tue, 27 Jun 00 14:09:39 +0100
Received: from irlbdc.irl.emea (irlbdc.baltimore.ie [192.168.20.3]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id OAA13977 for <[e-mail]>; Tue, 27 Jun 2000 14:09:39 +0100
Received: by irlbdc.cdsemea.baltimore.com with Internet Mail Service (5.5.2448.0) id <J5VJLP32>; Tue, 27 Jun 2000 14:09:34 +0100
Message-ID: <[e-mail]>
From: William Whyte <[e-mail]>
To: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-smime-idea-05.txt
Date: Tue, 27 Jun 2000 14:11:42 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

What's the difference between this draft and the -04 draft? It
doesn't seem that the issues raised on the list have been addressed.

Cheers,

William


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA00235 for ietf-smime-bks; Tue, 27 Jun 2000 03:43:38 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA00231 for <[e-mail]>; Tue, 27 Jun 2000 03:43:37 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06317; Tue, 27 Jun 2000 06:44:16 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-idea-05.txt
Date: Tue, 27 Jun 2000 06:44:15 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Use of the IDEA Encryption Algorithm in CMS
	Author(s)	: S. Teiwes, P. Hartmann, D. Kuenzi
	Filename	: draft-ietf-smime-idea-05.txt
	Pages		: 6
	Date		: 26-Jun-00
	
This memo specifies how to incorporate IDEA (International Data
Encryption Algorithm) [IDEA] into S/MIME [SMIME2, SMIME3] as 
an additional strong algorithm for symmetric encryption. For 
organizations who make use of IDEA for data security purposes 
it is of high interest that IDEA is also available in S/MIME. 
The intention of this memo is to provide the OIDs and algorithms 
required that IDEA can be included in S/MIME for symmetric content
and key encryption.

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

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

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

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id WAA13095 for ietf-smime-bks; Mon, 26 Jun 2000 22:44:48 -0700 (PDT)
Received: from mh.transparity.com (IDENT:root@[203.127.198.235]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA13091 for <[e-mail]>; Mon, 26 Jun 2000 22:44:45 -0700 (PDT)
Received: from transparity.com (xiaoying.secureage.com [203.127.198.231]) by mh.transparity.com (8.9.3/8.8.7) with ESMTP id NAA01858 for <[e-mail]>; Tue, 27 Jun 2000 13:51:39 +0800
Message-ID: <[e-mail]>
Date: Tue, 27 Jun 2000 13:56:19 +0800
From: Wu Xiao Ying <[e-mail]>
Organization: Transparity Ltd.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: smime <[e-mail]>
Subject: Re: SFL 1.6 on Linux compile problems
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

Here I'm trying to implement EnvelopedData 
KEKRecipientInfo RC2 key wrapping algorithm.
But my result is different from the example
given in draft-ietf-smime-examples. The problem
seemed to be at the RC2 encryption, but my 
Rc2 implementation has been tested with both IE 
and Netscape and works fine. So I doubt the 
example may have some error.

Anyone can help? Thanks a lot in advance.

Regards,
Xiaoying


Received: by ns.secondary.com (8.9.3/8.9.3) id JAA14799 for ietf-smime-bks; Mon, 26 Jun 2000 09:07:25 -0700 (PDT)
Received: from [165.227.249.13] (ip13.proper.com [165.227.249.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA14793; Mon, 26 Jun 2000 09:07:22 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p04320315b57d3040c0bf@[165.227.249.13]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 26 Jun 2000 09:07:57 -0700
To: Gunnar Kedenburg <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: SFL 1.6 on Linux compile problems
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 is the wrong mailing list for your question. Please send SFL 
questions to the [e-mail] mailing list.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: by ns.secondary.com (8.9.3/8.9.3) id IAA14342 for ietf-smime-bks; Mon, 26 Jun 2000 08:59:59 -0700 (PDT)
Received: from rzdspc1.informatik.uni-hamburg.de ([e-mail] [134.100.9.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14338 for <[e-mail]>; Mon, 26 Jun 2000 08:59:56 -0700 (PDT)
Received: from rzdspc3.informatik.uni-hamburg.de ([e-mail] [134.100.8.63]) by rzdspc1.informatik.uni-hamburg.de (8.10.1/8.10.1) with ESMTP id e5QG0Ub29464 for <[e-mail]>; Mon, 26 Jun 2000 18:00:30 +0200 (MET DST)
Received: (from 9kedenbu@localhost) by rzdspc3.informatik.uni-hamburg.de (8.10.1/8.10.1) id e5QG0UL14282 for [e-mail]; Mon, 26 Jun 2000 18:00:30 +0200 (MET DST)
Date: Mon, 26 Jun 2000 18:00:29 +0200
From: Gunnar Kedenburg <[e-mail]>
To: [e-mail]
Subject: SFL 1.6 on Linux compile problems
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
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>

Hello!
I am experiencing quite some problems compiling SFL 1.6 on Linux. First thing is that the distribution ZIP-file did not preserve uppercase letters in filenames. I fixed this for some files, but it would be nice to have a tar-file with the correct filenames. I am also trying to port SFL to an autoconf/automake build procedure, because the current makefile system didn't seem to work for us.
Has anybody done such work before, and is able to share his work with me? This would save me quite some time :)
Thanks
-- 
Gunnar.


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA07485 for ietf-smime-bks; Sat, 24 Jun 2000 18:13:08 -0700 (PDT)
Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA07479 for <[e-mail]>; Sat, 24 Jun 2000 18:13:07 -0700 (PDT)
Received: from jimsch1t (ip164.du1.bel.nwlink.com [209.20.136.164]) by smtp.nwlink.com (8.9.3/8.9.3) with ESMTP id SAA25522; Sat, 24 Jun 2000 18:13:32 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Blake Ramsdell'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Last Call: Use of the CAST-128 Encryption Algorithm in CMS to Proposed Standard
Date: Sat, 24 Jun 2000 18:13:56 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It would be called that I missed that issue on the IDEA draft since I was
still fixated over the fact that the encodings in the draft was wrong and
had not looked at the higher level.  Additionally, since I reviewed them at
different times, I did not have the same critiera all of the time. (I
suppose I should write it down so that I am more consistant :)

jim

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Jim Schaad
> Sent: Friday, June 23, 2000 1:10 PM
> To: Carlisle Adams; 'Blake Ramsdell'
> Cc: [e-mail]
> Subject: RE: Last Call: Use of the CAST-128 Encryption Algorithm in CMS
> to Proposed Standard
>
>
> This is still my position.  If, for a D-H key, you make the statment that
> CAST128 is supported as a bulk algorithm, then you must support
> the CAST128
> wrap of CAST128 because that is the only way of doing it.
>
> jim
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Carlisle Adams
> > Sent: Tuesday, June 20, 2000 7:19 AM
> > To: 'Blake Ramsdell'
> > Cc: '[e-mail]'
> > Subject: RE: Last Call: Use of the CAST-128 Encryption Algorithm in CMS
> > to Proposed Standard
> >
> >
> > Hi Blake,
> >
> > Good to hear from you again!
> >
> > > ----------
> > > From: 	Blake Ramsdell[SMTP:[e-mail]]
> > > Sent: 	Monday, June 19, 2000 4:14 PM
> > > To: 	'[e-mail]'
> > > Subject: 	RE: Last Call: Use of the CAST-128 Encryption Algorithm in
> > > CMS to Proposed Standard
> > >
> > > Two comments, don't know if they're major.
> > >
> > > 1. Section 3 does not list an SMIMECapability for key wrapping
> > using IDEA,
> > > only for symmetric encryption.  Don't know if that was intended.
> >
> > I suspect that you mean "CAST-128" above, rather than "IDEA"...
> >
> > In any case, I originally had both OIDs here (symm. encryption and key
> > wrapping), but in a note posted on Nov. 18, 1999, Jim Schaad
> included the
> > following comment:
> >
> > "2.  Section 3 Para 1.  You state that you must include the
> above OIDs in
> > the symmetric algorithms section of capabilities, but only one
> of the oids
> > is a symmetric algorithm.  At the
> > current time we are "implying" the key wrap from the symmetric
> > algorithm as
> > only same key wrap is supported in CMS.  Please change to the
> correct OID
> > reference."
> >
> > So, I took out the key wrap OID and left only the one for symmetric
> > encryption.
> >
> > > 2. I think that the example in section 3 should clarify that the
> > > cast5CBCParameters are encoded with the iv omitted.
> >
> > I guess it seemed clear to me that if you were only advertising your
> > capabilities (in this case, symmetric algorithm and key length),
> > an IV would
> > be irrelevant and would therefore be omitted.  If you wish,
> however, I can
> > add a sentence to this effect when the document has been approved
> > and I get
> > the 1-day window to send any tiny edits to the RFC editor.  Let
> me know if
> > you really think this is necessary.
> >
> > Thanks for taking the time to look through this draft!
> >
> > Carlisle.
> >
> >
>
>



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA06739 for ietf-smime-bks; Fri, 23 Jun 2000 14:38:56 -0700 (PDT)
Received: from citicorp.com (mango1-a.citicorp.com [192.193.196.140]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06731 for <[e-mail]>; Fri, 23 Jun 2000 14:38:54 -0700 (PDT)
From: [e-mail]
Received: from myrtle1.citicorp.com (imta.citicorp.com [192.193.196.186]) by citicorp.com (Pro-8.9.3/8.9.3) with ESMTP id RAA16043 for <[e-mail]>; Fri, 23 Jun 2000 17:33:09 -0400 (EDT)
Received: from x400prod2.cgin.us-md.citicorp.com (omroute4lan1.email.citicorp.com [163.39.249.74]) by myrtle1.citicorp.com (Pro-8.9.3/8.9.3) with ESMTP id JAA16935 for <[e-mail]>; Fri, 23 Jun 2000 09:21:22 -0400 (EDT)
Received: from mercury.lew.gb.citicorp.com (mercury.email.citicorp.com [169.166.15.228]) by x400prod2.cgin.us-md.citicorp.com (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id JAA07921 for <[e-mail]>; Fri, 23 Jun 2000 09:22:19 -0400 (EDT)
Received: from localhost (root@localhost) by mercury.lew.gb.citicorp.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id NAA28946 for [e-mail]; Fri, 23 Jun 2000 13:05:38 +0100 (BST)
X-OpenMail-Hops: 1
Date: Fri, 23 Jun 2000 13:05:25 +0100
Message-Id: <H000038a062efe92@MHS>
Subject: Canonicalisation of embedded MIME objects
MIME-Version: 1.0
TO: [e-mail]
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have noticed that a number of files as produced by different mail programs do 
not seem to be performing canonicalisation of inner objects correctly.

The inner objects use LF for line termination not CRLF pairs. It is my 
understanding that breaks MIME rules for canonicalising embedded objects.

To illustrate the problem I enclose a signed-then-encrypted message I have 
received:(I have removed the routing information)

The outer message appears as follows(All lines are terminated with <CRLF> 
pairs.).
-----------------------------------------------------------
Content-Type: application/pkcs7-mime; smime-type=encrypted-data;                
              name="xxx.p7m"                                                    
Content-Disposition: attachment; filename=xxx.p7m                               
Content-Transfer-Encoding: base64                                               
Message-ID: 19991015:080159:REF12345                                            
                                                                                
MIIbrgYJKoZIhvcNAQcDoIIbnzCCG5sCAQAxggHEMIHfAgEAMEgwQDELMAkGA1UEBhMCVVMx        
ETAPBgNVBAoTCENpdGljb3JwMR4wHAYDVQQLExVFbnRydXN0IERldmVsb3BtZW50IDICBDUa
:
:        
VgIT6ci+93vJE1yRs4la/s3WjmovuOg/PSWUwXiw11EbAmBoB6CitHYFM/Q5sC4RdXrwyH2l        
1y59mZTTTtLwr7AbuOlojs/KrIe51CYQMeu14XN/K1tKZXpmB0qgcyDmXq69WYEo+aKglqhJ        
--------------------------------------------------------------------------------
----


The embedded message looks as follows(All lines are terminated with <LF>).

----------------------------------------------------------------------------
Content-Type: application/pkcs7-mime; smime-type=signed-data;
              name="xxx.p7m"
Content-Disposition: attachment; filename=xxx.p7m
Content-Transfer-Encoding: base64
Message-ID: 19990225:131734:20499

MIIggQYJKoZIhvcNAQcCoIIgcjCCIG4CAQExCzAJBgUrDgMCGgUAMIISiwYJKoZIhvcNAQcB
:
:
mXw0F0zhCL+ZZdic+fmLh1BQ+rIkVu45zKfJVSI1/F9oyZdaVFMkt0NZaGdjSlvuG6deAhgZ
XJ0KskSW4qT5
-----------------------------------------------------------------------------


The inner application file looks as follows: With Content lines terminated with 
<LF> and the data segment with no line ends.

----------------------------------------------------------------------------
Content-Type: application/EDIFACT;
              name="xxx.edi"
Content-Transfer-Encoding: binary

UNA:+.? 'UNB+UNOA:1+



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


It is my interpretation that the use of <LF> to terminate the Content headers 
in the latter two messages above is not valid.

Can someone provide me with a definitive answer.

Thanks,
Bartley.






Received: by ns.secondary.com (8.9.3/8.9.3) id NAA02880 for ietf-smime-bks; Fri, 23 Jun 2000 13:15:01 -0700 (PDT)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA02861 for <[e-mail]>; Fri, 23 Jun 2000 13:14:57 -0700 (PDT)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.5); Fri, 23 Jun 2000 13:14:48 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2650.21) id <JKLWY1B8>; Fri, 23 Jun 2000 13:14:48 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Carlisle Adams" <[e-mail]>
cc: [e-mail]
Subject: RE: Last Call: Use of the CAST-128 Encryption Algorithm in CMS to Proposed Standard
Date: Fri, 23 Jun 2000 13:14:46 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 154D1AB216093-01-01
Content-Type: text/plain;  charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

So what's the difference between the CAST draft and the IDEA draft, then?
The IDEA draft specifies it, doesn't it?

Blake

-----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Friday, June 23, 2000 1:10 PM
To: Carlisle Adams; Blake Ramsdell
Cc: [e-mail]
Subject: RE: Last Call: Use of the CAST-128 Encryption Algorithm in CMS
to Proposed Standard


This is still my position.  If, for a D-H key, you make the statment that
CAST128 is supported as a bulk algorithm, then you must support the CAST128
wrap of CAST128 because that is the only way of doing it.

jim

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Carlisle Adams
> Sent: Tuesday, June 20, 2000 7:19 AM
> To: 'Blake Ramsdell'
> Cc: '[e-mail]'
> Subject: RE: Last Call: Use of the CAST-128 Encryption Algorithm in CMS
> to Proposed Standard
>
>
> Hi Blake,
>
> Good to hear from you again!
>
> > ----------
> > From: 	Blake Ramsdell[SMTP:[e-mail]]
> > Sent: 	Monday, June 19, 2000 4:14 PM
> > To: 	'[e-mail]'
> > Subject: 	RE: Last Call: Use of the CAST-128 Encryption Algorithm in
> > CMS to Proposed Standard
> >
> > Two comments, don't know if they're major.
> >
> > 1. Section 3 does not list an SMIMECapability for key wrapping
> using IDEA,
> > only for symmetric encryption.  Don't know if that was intended.
>
> I suspect that you mean "CAST-128" above, rather than "IDEA"...
>
> In any case, I originally had both OIDs here (symm. encryption and key
> wrapping), but in a note posted on Nov. 18, 1999, Jim Schaad included the
> following comment:
>
> "2.  Section 3 Para 1.  You state that you must include the above OIDs in
> the symmetric algorithms section of capabilities, but only one of the oids
> is a symmetric algorithm.  At the
> current time we are "implying" the key wrap from the symmetric
> algorithm as
> only same key wrap is supported in CMS.  Please change to the correct OID
> reference."
>
> So, I took out the key wrap OID and left only the one for symmetric
> encryption.
>
> > 2. I think that the example in section 3 should clarify that the
> > cast5CBCParameters are encoded with the iv omitted.
>
> I guess it seemed clear to me that if you were only advertising your
> capabilities (in this case, symmetric algorithm and key length),
> an IV would
> be irrelevant and would therefore be omitted.  If you wish, however, I can
> add a sentence to this effect when the document has been approved
> and I get
> the 1-day window to send any tiny edits to the RFC editor.  Let me know if
> you really think this is necessary.
>
> Thanks for taking the time to look through this draft!
>
> Carlisle.
>
>





Received: by ns.secondary.com (8.9.3/8.9.3) id NAA02025 for ietf-smime-bks; Fri, 23 Jun 2000 13:09:12 -0700 (PDT)
Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA02021 for <[e-mail]>; Fri, 23 Jun 2000 13:09:11 -0700 (PDT)
Received: from jimsch1t (ip162.du1.bel.nwlink.com [209.20.136.162]) by smtp.nwlink.com (8.9.3/8.9.3) with ESMTP id NAA03731; Fri, 23 Jun 2000 13:09:28 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "Carlisle Adams" <[e-mail]>, "'Blake Ramsdell'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Last Call: Use of the CAST-128 Encryption Algorithm in CMS to Proposed Standard
Date: Fri, 23 Jun 2000 13:09:53 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
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 still my position.  If, for a D-H key, you make the statment that
CAST128 is supported as a bulk algorithm, then you must support the CAST128
wrap of CAST128 because that is the only way of doing it.

jim

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Carlisle Adams
> Sent: Tuesday, June 20, 2000 7:19 AM
> To: 'Blake Ramsdell'
> Cc: '[e-mail]'
> Subject: RE: Last Call: Use of the CAST-128 Encryption Algorithm in CMS
> to Proposed Standard
>
>
> Hi Blake,
>
> Good to hear from you again!
>
> > ----------
> > From: 	Blake Ramsdell[SMTP:[e-mail]]
> > Sent: 	Monday, June 19, 2000 4:14 PM
> > To: 	'[e-mail]'
> > Subject: 	RE: Last Call: Use of the CAST-128 Encryption Algorithm in
> > CMS to Proposed Standard
> >
> > Two comments, don't know if they're major.
> >
> > 1. Section 3 does not list an SMIMECapability for key wrapping
> using IDEA,
> > only for symmetric encryption.  Don't know if that was intended.
>
> I suspect that you mean "CAST-128" above, rather than "IDEA"...
>
> In any case, I originally had both OIDs here (symm. encryption and key
> wrapping), but in a note posted on Nov. 18, 1999, Jim Schaad included the
> following comment:
>
> "2.  Section 3 Para 1.  You state that you must include the above OIDs in
> the symmetric algorithms section of capabilities, but only one of the oids
> is a symmetric algorithm.  At the
> current time we are "implying" the key wrap from the symmetric
> algorithm as
> only same key wrap is supported in CMS.  Please change to the correct OID
> reference."
>
> So, I took out the key wrap OID and left only the one for symmetric
> encryption.
>
> > 2. I think that the example in section 3 should clarify that the
> > cast5CBCParameters are encoded with the iv omitted.
>
> I guess it seemed clear to me that if you were only advertising your
> capabilities (in this case, symmetric algorithm and key length),
> an IV would
> be irrelevant and would therefore be omitted.  If you wish, however, I can
> add a sentence to this effect when the document has been approved
> and I get
> the 1-day window to send any tiny edits to the RFC editor.  Let me know if
> you really think this is necessary.
>
> Thanks for taking the time to look through this draft!
>
> Carlisle.
>
>



Received: by ns.secondary.com (8.9.3/8.9.3) id MAA00870 for ietf-smime-bks; Fri, 23 Jun 2000 12:35:44 -0700 (PDT)
Received: from [165.227.249.13] (ip13.proper.com [165.227.249.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00859; Fri, 23 Jun 2000 12:35:11 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0432030fb5796ba44ee0@[165.227.249.13]>
In-Reply-To:  <[e-mail]>
References: <[e-mail]>
Date: Fri, 23 Jun 2000 12:35:29 -0700
To: Philip Hallam-Baker <[e-mail]>, "'[e-mail]'" <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: New patent claim
Cc: [e-mail], [e-mail], [e-mail]
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>

At 12:16 PM -0700 6/23/00, Philip Hallam-Baker wrote:
>The working group does not have any budget for any purpose (as far as
>I am aware).

For those of you not familiar with Phill's dry Brit humor (surely he 
writes for NTK?), the IETF does not spend money researching laws. It 
never has. In fact, they did not research whether or not they should 
have posted the IPR statement that started this thread: they just did 
it blindly, as they do with all the rest of them. It is up to you to 
decide whether or not the patent is valid, applies to anything you 
are doing, and so on.

(And, before someone posts a "why not" type response, might I remind 
you that you all paid no money to be members of the IETF? That might 
give you a clue....)

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA26980 for ietf-smime-bks; Fri, 23 Jun 2000 12:17:04 -0700 (PDT)
Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA26917; Fri, 23 Jun 2000 12:17:00 -0700 (PDT)
Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id MAA26250; Fri, 23 Jun 2000 12:17:18 -0700 (PDT)
Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id <NMK06QCW>; Fri, 23 Jun 2000 12:16:04 -0700
Message-ID: <[e-mail]>
From: Philip Hallam-Baker <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Philip Hallam-Baker <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: New patent claim
Date: Fri, 23 Jun 2000 12:16:03 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="----=_NextPart_000_0020_01BFDD26.1891B040"; protocol="application/x-pkcs7-signature"; micalg=SHA1
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0020_01BFDD26.1891B040
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

The working group does not have any budget for any purpose (as far as
I am aware).

Obtaining a non-infringement opinion on even the most ridiculous claim
costs may tens of thousands of dollars in legal time and at least as 
much in engineer time - if you can find one prepared to spend that much
time talking to lawyers.

Under UK law there is actually a tort of demanding monies based on
a bogus intellectual property claim.

I'd rather apply to the US patent office for a patent on some critical
biological function which according to the USPTO motto 'ask and ye 
shall receive' would inevitably be granted. Then if anyone ever sued
we could file a cross claim and demand an injunction demanding that
they cease the bodily functions concerned pending the outcome of the
case.

		Phill

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Friday, June 23, 2000 9:41 AM
To: Philip Hallam-Baker
Cc: [e-mail]; [e-mail];
[e-mail]; [e-mail]
Subject: RE: New patent claim



Et all,
While I agree with Phil that the claims do not seem connected. I wonder
if
the S/MIME group has access
to a legal staff and could ask the question?
Mike McClennan
Director of Marketing - Secure Messaging
Tel: [phone]
------------------------------------------------------------------------
----------

Keep your data safe!  Encryption for your email.
Click here:  http://www.jawstech.com/store


 

                    Philip Hallam-Baker

                    <[e-mail]        To:     "'Bruce
Greenblatt'"                       
                    m>
<[e-mail]>, Paul     
                    Sent by:                   Hoffman / IMC
<[e-mail]>,                  
                    owner-ietf-smime@ma        [e-mail]

                    il.imc.org                 cc:

                                               Subject:     RE: New
patent claim                  
 

                    06/22/00 10:48 AM

 

 





I also read the claims. I cannot see the connection.

What did come to mind as a possibility was that some lawyer persuaded
his client that he had to file the notice (and charged him a couple of
hundred bucks for doing so).


          Phill




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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw
ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow
ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp
c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l
bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5
6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK
QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB
rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg
hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD
AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy
Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I
98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A
ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD
Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy
MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF
bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU
NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh
1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA
AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f
BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG
SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC
AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz
7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R
dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6
xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g
dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc
VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5
NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50
czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g
23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9
vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ
BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t
L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV
HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB
MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC
MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l
BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV
BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d
qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS
MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD
bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDYyMzE5MTcwOFowIwYJKoZI
hvcNAQkEMRYEFHViAmORUoBVEllvWaQt8U0HJ5uPMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3
DQEBAQUABIGANYjzGs3G1E+z+QndpeVqsi03XK9roWNAHLmHG+JftStA5zvkdr93EpaAMfxMlgP3
gRny/OJsnz/WoN97CEx5g5OJBVDqu7j/mMZkKdIeHsOMnAxk+bEXLuZRsuu/OLRQ+HfUo7h/fUGv
lr/NO5Dtqs45RbhW2pL1Su6NeBIDKXsAAAAAAAA=

------=_NextPart_000_0020_01BFDD26.1891B040--



Received: by ns.secondary.com (8.9.3/8.9.3) id JAA23021 for ietf-smime-bks; Fri, 23 Jun 2000 09:52:27 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA23015 for <[e-mail]>; Fri, 23 Jun 2000 09:52:25 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 23 Jun 2000 10:52:11 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Fri, 23 Jun 2000 10:52:01 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Last Call: Use of the CAST-128 Encryption Algorithm in CMS toProposed Standard
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id JAA23017
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 will raise the same objection that I raised within the S/MIME working group.

I have nothing against the CAST-128 algorithm per se, or against proprietary algorithms in general, but I am strongly opposed to including more and more algorithms within the S/MIME suite that really don't provide any significant or measurable improvement in security when compared to existing choices.

The fact that such algorithms are considered "standard", even if they are optional, inevitably leads to competitive pressure to include those algorithms within e-mail packages, as well as cryptographic toolkits.  The inclusion in the cryptographic infrastructure then tends to proliferate to other programs and applications as well. This leads to greatly increased development, test, and documentation costs within the vendor community, as well as to code bloat and interoperability headaches, but with no significant benefit to the users.

I see absolutely no reason to include CAST, IDEA, or some of the other algorithms that have recently been proposed, when AES  is about to come out.

I would encourage the IESG to "just say no" to the "let 10,000 standards bloom" type of mentality, and to make the necessary hard choices. I believe that this should be an informational RFC, and not a Proposed Standard.

Sincerely,

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
1800 South novell Place
Provo, Utah 80606
801/861-7387




>>> [e-mail] 06/16/00 11:27AM >>>

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

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

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-smime-cast-128-02.txt 




Received: by ns.secondary.com (8.9.3/8.9.3) id HAA15406 for ietf-smime-bks; Fri, 23 Jun 2000 07:00:57 -0700 (PDT)
Received: from ns1.futurelink.net ([207.229.55.254]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA15395; Fri, 23 Jun 2000 07:00:55 -0700 (PDT)
From: [e-mail]
Received: from mail.jawstech.com by ns1.futurelink.net via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 23 Jun 2000 14:01:15 UT
Subject: RE: New patent claim
To: Philip Hallam-Baker <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.2c  February 2, 2000
Message-ID: <[e-mail]>
Date: Fri, 23 Jun 2000 09:41:29 -0400
X-MIMETrack: Serialize by Router on jawnotes1/Jawstech(Release 5.0.2c |February 2, 2000) at 06/23/2000 07:56:43 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Et all,
While I agree with Phil that the claims do not seem connected. I wonder if
the S/MIME group has access
to a legal staff and could ask the question?
Mike McClennan
Director of Marketing - Secure Messaging
Tel: [phone]
----------------------------------------------------------------------------------

Keep your data safe!  Encryption for your email.
Click here:  http://www.jawstech.com/store


                                                                                                  
                    Philip Hallam-Baker                                                           
                    <[e-mail]        To:     "'Bruce Greenblatt'"                       
                    m>                         <[e-mail]>, Paul     
                    Sent by:                   Hoffman / IMC <[e-mail]>,                  
                    owner-ietf-smime@ma        [e-mail]                                 
                    il.imc.org                 cc:                                                
                                               Subject:     RE: New patent claim                  
                                                                                                  
                    06/22/00 10:48 AM                                                             
                                                                                                  
                                                                                                  




I also read the claims. I cannot see the connection.

What did come to mind as a possibility was that some lawyer persuaded
his client that he had to file the notice (and charged him a couple of
hundred bucks for doing so).


          Phill






Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA18365 for ietf-smime-bks; Thu, 22 Jun 2000 09:11:44 -0700 (PDT)
Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18359 for <[e-mail]>; Thu, 22 Jun 2000 09:11:43 -0700 (PDT)
From: [e-mail]
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id <NN4JJQFX>; Thu, 22 Jun 2000 12:12:44 -0400
Message-ID: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: RE: CMS Compressed Data Content Type
Date: Thu, 22 Jun 2000 12:12:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDC64.B1FC98E8"
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_01BFDC64.B1FC98E8
Content-Type: text/plain;
	charset="iso-8859-1"

Russ,

I understand from the Final 29 March 2000 S/MIME WG Minutes that you
mentioned about the issue of a MIME compress data type that Jeff Schiller
recommended that the S/MIME WG "just do it" because the issue needs to be
resolved for efficiency purposes.

There are currently two other Internet Draft were this same issue of a MIME
compress data type has been brought up:

a. The Internet Draft "draft-ietf-ediint-as1-11.txt" about MIME-based Secure
EDI from the Electronic Data Interchange Internet Integration (EDIINT) WG
also has a requirement for a MIME compress data type, but mentions the
following in Section 5.4.1:

"Applying compression before encryption strengthens cryptographic security
since repetitious strings are reduced. This sequence of signature,
compression, then encryption, or compression then encryption, is consistent
with the order in which PGP implementations handle compression.            
       
Note: Compression is done automatically when using PGP encryption.

The MIME standards do not define a way in which to convey that a message has
been compressed. However, RFC2045 does allow the definition of additional
MIME header fields to further describe the content of a message.

RFC2068, the HTTP/1.1 specification does define a Content-Encoding field
that is primarily used to convey compression information: 
 
        Content-Encoding = "Content-Encoding" ":" content-coding

where content-coding can take on the values of "gzip" or "compress". The
gzip compression standard is further described in RFC 1952, and compress is
the standard UNIX file compression program. Both gzip and compress are
registered with IANA."

b. The Internet Draft "draft-ietf-avt-rtp-mime-02.txt" about MIME Type
Registration of Real-time Transport Protocol (RTP) Payload Formats from the
Audio/Video Transport (AVT) WG on the other hand is using MIME registration
procedure described in RFC2048 to register MIME subtype names for use with
the RTP [RFC1889], including various data compression formats for audio and
video.

Should not the S/MIME WG just do it and create a standard interoperable MIME
compress data type as proposed by Peter, which could be used by both the
S/MIME WG and the EDIINT WG?

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[e-mail]      Tel. [phone] ext. 419
http://www.chrysalis-its.com     Fax. [phone]


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Tuesday, June 20, 2000 11:04 AM
To: [e-mail]
Cc: [e-mail]
Subject: CMS Compressed Data Content Type


Peter,

Do you plan to update your Internet Draft on the S/MIME compressed data
content type, which expired on April 2000?

I would much prefer having a standard and interoperable way of compressing
data before performing encryption than having a different proprietary
approach from each vendor.

Francois 
___________________________________ 
Francois Rousseau 
Director of Standards and Conformance 
Chrysalis-ITS 
1688 Woodward Drive 
Ottawa, Ontario, CANADA, K2C 3R7 
[e-mail]      Tel. [phone] ext. 419 
http://www.chrysalis-its.com     Fax. [phone]

------_=_NextPart_001_01BFDC64.B1FC98E8
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>RE: CMS Compressed Data Content Type</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Russ,</FONT>
</P>

<P><FONT SIZE=3D2>I understand from the Final 29 March 2000 S/MIME WG =
Minutes that you mentioned about the issue of a MIME compress data type =
that Jeff Schiller recommended that the S/MIME WG &quot;just do =
it&quot; because the issue needs to be resolved for efficiency =
purposes.</FONT></P>

<P><FONT SIZE=3D2>There are currently two other Internet Draft were =
this same issue of a MIME compress data type has been brought =
up:</FONT>
</P>

<P><FONT SIZE=3D2>a. The Internet Draft =
&quot;draft-ietf-ediint-as1-11.txt&quot; about MIME-based Secure EDI =
from the Electronic Data Interchange Internet Integration (EDIINT) WG =
also has a requirement for a MIME compress data type, but mentions the =
following in Section 5.4.1:</FONT></P>

<P><FONT SIZE=3D2>&quot;Applying compression before encryption =
strengthens cryptographic security since repetitious strings are =
reduced. This sequence of signature, compression, then encryption, or =
compression then encryption, is consistent with the order in which PGP =
implementations handle =
compression.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; </FONT></P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>Note: Compression is done automatically when using =
PGP encryption.</FONT>
</P>

<P><FONT SIZE=3D2>The MIME standards do not define a way in which to =
convey that a message has been compressed. However, RFC2045 does allow =
the definition of additional MIME header fields to further describe the =
content of a message.</FONT></P>

<P><FONT SIZE=3D2>RFC2068, the HTTP/1.1 specification does define a =
Content-Encoding field that is primarily used to convey compression =
information: </FONT></P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Content-Encoding =3D &quot;Content-Encoding&quot; &quot;:&quot; =
content-coding</FONT>
</P>

<P><FONT SIZE=3D2>where content-coding can take on the values of =
&quot;gzip&quot; or &quot;compress&quot;. The gzip compression standard =
is further described in RFC 1952, and compress is the standard UNIX =
file compression program. Both gzip and compress are registered with =
IANA.&quot;</FONT></P>

<P><FONT SIZE=3D2>b. The Internet Draft =
&quot;draft-ietf-avt-rtp-mime-02.txt&quot; about MIME Type Registration =
of Real-time Transport Protocol (RTP) Payload Formats from the =
Audio/Video Transport (AVT) WG on the other hand is using MIME =
registration procedure described in RFC2048 to register MIME subtype =
names for use with the RTP [RFC1889], including various data =
compression formats for audio and video.</FONT></P>

<P><FONT SIZE=3D2>Should not the S/MIME WG just do it and create a =
standard interoperable MIME compress data type as proposed by Peter, =
which could be used by both the S/MIME WG and the EDIINT WG?</FONT></P>

<P><FONT SIZE=3D2>Francois</FONT>
<BR><FONT SIZE=3D2>___________________________________</FONT>
<BR><FONT SIZE=3D2>Francois Rousseau</FONT>
<BR><FONT SIZE=3D2>Director of Standards and Conformance</FONT>
<BR><FONT SIZE=3D2>Chrysalis-ITS</FONT>
<BR><FONT SIZE=3D2>1688 Woodward Drive</FONT>
<BR><FONT SIZE=3D2>Ottawa, Ontario, CANADA, K2C 3R7</FONT>
<BR><FONT =
SIZE=3D2>[e-mail]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel. =
[phone] ext. 419</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.chrysalis-its.com" =
TARGET=3D"_blank">http://www.chrysalis-its.com</A>&nbsp;&nbsp;&nbsp;&nbs=
p; Fax. [phone]</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [e-mail] [<A =
HREF=3D"mailto:[e-mail]">mailto:FRousseau@chrysalis-i=
ts.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, June 20, 2000 11:04 AM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: CMS Compressed Data Content Type</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Peter,</FONT>
</P>

<P><FONT SIZE=3D2>Do you plan to update your Internet Draft on the =
S/MIME compressed data content type, which expired on April =
2000?</FONT>
</P>

<P><FONT SIZE=3D2>I would much prefer having a standard and =
interoperable way of compressing data before performing encryption than =
having a different proprietary approach from each vendor.</FONT></P>

<P><FONT SIZE=3D2>Francois </FONT>
<BR><FONT SIZE=3D2>___________________________________ </FONT>
<BR><FONT SIZE=3D2>Francois Rousseau </FONT>
<BR><FONT SIZE=3D2>Director of Standards and Conformance </FONT>
<BR><FONT SIZE=3D2>Chrysalis-ITS </FONT>
<BR><FONT SIZE=3D2>1688 Woodward Drive </FONT>
<BR><FONT SIZE=3D2>Ottawa, Ontario, CANADA, K2C 3R7 </FONT>
<BR><FONT =
SIZE=3D2>[e-mail]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel. =
[phone] ext. 419 </FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.chrysalis-its.com" =
TARGET=3D"_blank">http://www.chrysalis-its.com</A>&nbsp;&nbsp;&nbsp;&nbs=
p; Fax. [phone]</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFDC64.B1FC98E8--


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA14538 for ietf-smime-bks; Thu, 22 Jun 2000 07:49:15 -0700 (PDT)
Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA14531; Thu, 22 Jun 2000 07:49:14 -0700 (PDT)
Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id HAA07841; Thu, 22 Jun 2000 07:46:59 -0700 (PDT)
Received: by postal-gw2.verisign.com with Internet Mail Service (5.5.2650.21) id <NMJZKYAC>; Thu, 22 Jun 2000 07:48:23 -0700
Message-ID: <[e-mail]>
From: Philip Hallam-Baker <[e-mail]>
To: "'Bruce Greenblatt'" <[e-mail]>, Paul Hoffman / IMC <[e-mail]>, [e-mail]
Subject: RE: New patent claim
Date: Thu, 22 Jun 2000 07:48:22 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0000_01BFDC37.89A2C0C0"; protocol="application/x-pkcs7-signature"
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01BFDC37.89A2C0C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I also read the claims. I cannot see the connection. 

What did come to mind as a possibility was that some lawyer persuaded
his client that he had to file the notice (and charged him a couple of
hundred bucks for doing so).


		Phill

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw
ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow
ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp
c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l
bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5
6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK
QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB
rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg
hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD
AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy
Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I
98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A
ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD
Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy
MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF
bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU
NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh
1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA
AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f
BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG
SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC
AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz
7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R
dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6
xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g
dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc
VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5
NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50
czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g
23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9
vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ
BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t
L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV
HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB
MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC
MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l
BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV
BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d
qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS
MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD
bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDYyMjE0NDkyN1owIwYJKoZI
hvcNAQkEMRYEFL6z+xKRPcemL97fLjv0fcedyt0sMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3
DQEBAQUABIGAptImX6Lw/ag0m8xF8xToazZqDTQl0JK6F1GWQwSO8eoc8ynqdq8wSYxZHpJzbPi3
+PB2lWd8yWG68mi6iQZypQQrGTLpLYvrEdIQ7vAXicf0+84cauGlMaBi8etb0VNdMvpxB+l6hyye
EPSba/Q5jnIi8hfamKz+HDXUyq/j4D8AAAAAAAA=

------=_NextPart_000_0000_01BFDC37.89A2C0C0--



Received: by ns.secondary.com (8.9.3/8.9.3) id FAA10351 for ietf-smime-bks; Thu, 22 Jun 2000 05:27:28 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10347 for <[e-mail]>; Thu, 22 Jun 2000 05:27:26 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27600; Thu, 22 Jun 2000 08:27:40 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-cms-rsaes-oaep-01.txt
Date: Thu, 22 Jun 2000 08:27:40 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Use of the RSAES-OAEP Transport Algorithm in CMS	
        Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cms-rsaes-oaep-01.txt
	Pages		: 8
	Date		: 21-Jun-00
	
This document describes the use of the RSAES-OAEP key transport
method of key management within the Cryptographic Message Syntax
[CMS].
This draft is being discussed on the 'ietf-smime' mailing list.  To
join the list, send a message to <[e-mail]> with
the single word 'subscribe' in the body of the message.  Also, there
is a Web site for the mailing list at <http://www.imc.org/ietf-
smime/>.

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

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

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

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

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id PAA02344 for ietf-smime-bks; Wed, 21 Jun 2000 15:59:50 -0700 (PDT)
Received: from ps2.walltech.com (ps2.walltech.com [207.5.77.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA02338; Wed, 21 Jun 2000 15:59:49 -0700 (PDT)
Received: from bgg1.directory-applications.com (goldengate-bridge.veritas.com [63.197.92.2]) by ps2.walltech.com (8.10.0/8.10.0/walltech-2.10) with ESMTP id e5LN00623043; Wed, 21 Jun 2000 16:00:00 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Wed, 21 Jun 2000 16:01:22 -0700
To: Paul Hoffman / IMC <[e-mail]>, [e-mail]
From: Bruce Greenblatt <[e-mail]>
Subject: Re: New patent claim
In-Reply-To: <p04320304b5769dfeb1e9@[165.227.249.13]>
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>

At 09:30 AM 06/21/2000 -0700, Paul Hoffman / IMC wrote:
>Someone is claiming a patent on parts of S/MIME. See 
><http://www.ietf.org/ietf/IPR/HALL-SMIME>.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
IBM's patent server says 
(http://patent.womplex.ibm.com/details?&pn=US05126728__):

What is claimed is:
                      1. A data processing security device comprising:

                      a) memory means for storing a plurality of authorized 
field protection introducer codes,
                      b) means for evaluating a stream of data flowing from 
a source of character codes to identify
                      field protection introducer codes within the stream 
of data, said means for evaluating being in
                      communication with said memory means, said evaluating 
means comprising comparison
                      means for comparing introducer codes within the 
stream of data to said authorized codes in
                      said memory means, and
                      c) means for replacing data after said field 
introducer codes within said stream of data with
                      replacement characters if the field introducer codes 
within the stream of data do not match at
                      least one of said authorized codes stored in said 
memory means, said means for replacing
                      being in communication with said evaluating means.


This doesn't seem like it applies to me.  I know that message security 
labels have been around forever (at least as far back as X.400 1988) in the 
email world.  It is also very hardware oriented...

Bruce



Received: by ns.secondary.com (8.9.3/8.9.3) id KAA26558 for ietf-smime-bks; Wed, 21 Jun 2000 10:16:22 -0700 (PDT)
Received: from btw.plaintalk.bellevue.wa.us (btw-xl1.plaintalk.bellevue.wa.us [206.129.5.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA26551; Wed, 21 Jun 2000 10:16:20 -0700 (PDT)
Received: from software-munitions.com (fwiw.plaintalk.bellevue.wa.us [206.129.5.157]) by btw.plaintalk.bellevue.wa.us (8.10.1/8.10.1) with ESMTP id e5LHFpg50665; Wed, 21 Jun 2000 10:15:51 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 21 Jun 2000 10:15:51 -0700
From: Dennis Glatting <[e-mail]>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Hoffman / IMC <[e-mail]>
CC: [e-mail]
Subject: Re: New patent claim
References: <p04320304b5769dfeb1e9@[165.227.249.13]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul Hoffman / IMC wrote:
> 
> Someone is claiming a patent on parts of S/MIME. See
> <http://www.ietf.org/ietf/IPR/HALL-SMIME>.
> 

I recognize the domain ex-pressnet.com. I was just spammed by them.
Perhaps that is an indication of their business model?


Received: by ns.secondary.com (8.9.3/8.9.3) id JAA22389 for ietf-smime-bks; Wed, 21 Jun 2000 09:30:44 -0700 (PDT)
Received: from [165.227.249.13] (ip13.proper.com [165.227.249.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA22375 for <[e-mail]>; Wed, 21 Jun 2000 09:30:42 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p04320304b5769dfeb1e9@[165.227.249.13]>
Date: Wed, 21 Jun 2000 09:30:33 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: New patent claim
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>

Someone is claiming a patent on parts of S/MIME. See 
<http://www.ietf.org/ietf/IPR/HALL-SMIME>.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: by ns.secondary.com (8.9.3/8.9.3) id KAA20541 for ietf-smime-bks; Tue, 20 Jun 2000 10:52:49 -0700 (PDT)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA20535 for <[e-mail]>; Tue, 20 Jun 2000 10:52:48 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.209]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id KAA18495 for <[e-mail]>; Tue, 20 Jun 2000 10:52:21 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 20 Jun 2000 13:25:43 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Agenda Topics
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>

WG Members:

I am starting to put together the agenda for the IETF meeting in July.  If 
you would like a time slot in the two hour meeting, please send me 
e-mail.  Please reply to this note, but do not copy the whole list.

Thanks,
   Russ


Received: by ns.secondary.com (8.9.3/8.9.3) id IAA09870 for ietf-smime-bks; Tue, 20 Jun 2000 08:03:42 -0700 (PDT)
Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09864 for <[e-mail]>; Tue, 20 Jun 2000 08:03:40 -0700 (PDT)
From: [e-mail]
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id <NJTD7312>; Tue, 20 Jun 2000 11:04:20 -0400
Message-ID: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: CMS Compressed Data Content Type
Date: Tue, 20 Jun 2000 11:04:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDAC8.CF7D23E4"
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_01BFDAC8.CF7D23E4
Content-Type: text/plain;
	charset="iso-8859-1"

Peter,

Do you plan to update your Internet Draft on the S/MIME compressed data
content type, which expired on April 2000?

I would much prefer having a standard and interoperable way of compressing
data before performing encryption than having a different proprietary
approach from each vendor.

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[e-mail]      Tel. [phone] ext. 419
http://www.chrysalis-its.com     Fax. [phone]


------_=_NextPart_001_01BFDAC8.CF7D23E4
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>CMS Compressed Data Content Type</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Peter,</FONT>
</P>

<P><FONT SIZE=3D2>Do you plan to update your Internet Draft on the =
S/MIME compressed data content type, which expired on April =
2000?</FONT>
</P>

<P><FONT SIZE=3D2>I would much prefer having a standard and =
interoperable way of compressing data before performing encryption than =
having a different proprietary approach from each vendor.</FONT></P>

<P><FONT SIZE=3D2>Francois</FONT>
<BR><FONT SIZE=3D2>___________________________________</FONT>
<BR><FONT SIZE=3D2>Francois Rousseau</FONT>
<BR><FONT SIZE=3D2>Director of Standards and Conformance</FONT>
<BR><FONT SIZE=3D2>Chrysalis-ITS</FONT>
<BR><FONT SIZE=3D2>1688 Woodward Drive</FONT>
<BR><FONT SIZE=3D2>Ottawa, Ontario, CANADA, K2C 3R7</FONT>
<BR><FONT =
SIZE=3D2>[e-mail]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel. =
[phone] ext. 419</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.chrysalis-its.com" =
TARGET=3D"_blank">http://www.chrysalis-its.com</A>&nbsp;&nbsp;&nbsp;&nbs=
p; Fax. [phone]</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFDAC8.CF7D23E4--


Received: by ns.secondary.com (8.9.3/8.9.3) id HAA07989 for ietf-smime-bks; Tue, 20 Jun 2000 07:20:02 -0700 (PDT)
Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07982 for <[e-mail]>; Tue, 20 Jun 2000 07:20:01 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <NFRN311J>; Tue, 20 Jun 2000 10:19:35 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Blake Ramsdell'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Last Call: Use of the CAST-128 Encryption Algorithm in CMS to Proposed Standard
Date: Tue, 20 Jun 2000 10:19:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Blake,

Good to hear from you again!

> ----------
> From: 	Blake Ramsdell[SMTP:[e-mail]]
> Sent: 	Monday, June 19, 2000 4:14 PM
> To: 	'[e-mail]'
> Subject: 	RE: Last Call: Use of the CAST-128 Encryption Algorithm in
> CMS to Proposed Standard
> 
> Two comments, don't know if they're major.
> 
> 1. Section 3 does not list an SMIMECapability for key wrapping using IDEA,
> only for symmetric encryption.  Don't know if that was intended.
 
I suspect that you mean "CAST-128" above, rather than "IDEA"...

In any case, I originally had both OIDs here (symm. encryption and key
wrapping), but in a note posted on Nov. 18, 1999, Jim Schaad included the
following comment:

"2.  Section 3 Para 1.  You state that you must include the above OIDs in
the symmetric algorithms section of capabilities, but only one of the oids
is a symmetric algorithm.  At the
current time we are "implying" the key wrap from the symmetric algorithm as
only same key wrap is supported in CMS.  Please change to the correct OID
reference."

So, I took out the key wrap OID and left only the one for symmetric
encryption.

> 2. I think that the example in section 3 should clarify that the
> cast5CBCParameters are encoded with the iv omitted.
 
I guess it seemed clear to me that if you were only advertising your
capabilities (in this case, symmetric algorithm and key length), an IV would
be irrelevant and would therefore be omitted.  If you wish, however, I can
add a sentence to this effect when the document has been approved and I get
the 1-day window to send any tiny edits to the RFC editor.  Let me know if
you really think this is necessary.

Thanks for taking the time to look through this draft!

Carlisle.



Received: by ns.secondary.com (8.9.3/8.9.3) id NAA26520 for ietf-smime-bks; Mon, 19 Jun 2000 13:14:45 -0700 (PDT)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA26516 for <[e-mail]>; Mon, 19 Jun 2000 13:14:44 -0700 (PDT)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.5); Mon, 19 Jun 2000 13:14:15 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2650.21) id <JKLWYB77>; Mon, 19 Jun 2000 13:14:14 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Last Call: Use of the CAST-128 Encryption Algorithm in CMS to Proposed Standard
Date: Mon, 19 Jun 2000 13:14:07 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 1550A09D54874-01-01
Content-Type: text/plain;  charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Two comments, don't know if they're major.

1. Section 3 does not list an SMIMECapability for key wrapping using IDEA,
only for symmetric encryption.  Don't know if that was intended.

2. I think that the example in section 3 should clarify that the
cast5CBCParameters are encoded with the iv omitted.

Blake

-----Original Message-----
From: The IESG [mailto:[e-mail]]
Sent: Friday, June 16, 2000 10:27 AM
Cc: [e-mail]
Subject: Last Call: Use of the CAST-128 Encryption Algorithm in CMS to
Proposed Standard



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

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

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-smime-cast-128-02.txt




Received: by ns.secondary.com (8.9.3/8.9.3) id KAA19926 for ietf-smime-bks; Fri, 16 Jun 2000 10:27:44 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19922 for <[e-mail]>; Fri, 16 Jun 2000 10:27:42 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17845; Fri, 16 Jun 2000 13:27:26 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: [e-mail]
From: The IESG <[e-mail]>
SUBJECT: Last Call: Use of the CAST-128 Encryption Algorithm in CMS to Proposed Standard
Reply-to: [e-mail]
Date: Fri, 16 Jun 2000 13:27:26 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

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

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-smime-cast-128-02.txt



Received: by ns.secondary.com (8.9.3/8.9.3) id AAA18114 for ietf-smime-bks; Fri, 16 Jun 2000 00:14:20 -0700 (PDT)
Received: from smtp01.hk.linkage.net (smtp01.hk.linkage.net [210.184.16.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA18110 for <[e-mail]>; Fri, 16 Jun 2000 00:14:17 -0700 (PDT)
Received: from novell.beautyforest.com.hk ([203.85.85.200]) by smtp01.hk.linkage.net (8.9.3/8.9.3) with ESMTP id PAA10139; Fri, 16 Jun 2000 15:11:19 +0800 (HKT)
Received: from BEAUTY/SpoolDir by novell.beautyforest.com.hk (Mercury 1.48); 16 Jun 00 15:08:12 GMT+0800
Received: from SpoolDir by BEAUTY (Mercury 1.48); 16 Jun 00 14:45:09 GMT+0800
Received: from host (209.206.11.160) by novell.beautyforest.com.hk (Mercury 1.48) with ESMTP; 16 Jun 00 14:44:58 GMT+0800
From: "Owen Carlson" <[e-mail]>
Subject: Your business depends on it #5192
To: [e-mail]
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3
Mime-Version: 1.0
Date: Fri, 16 Jun 2000 00:01:58 -0500
Content-Type: text/plain; charset="iso-8859-1"
Message-ID: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA18111
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>

Email marketing is starting to boom and 
you're probably wondering how you can 
capitalize on this phenomenal advertising 
method. Well..here is your chance!
 
As e-commerce grows, you need to stay 
on top of your competition and keep up with
the technology.  
 
GENIUS MARKETING STRATEGIES CAN HELP!
 
We can target a market that will advertise
your business effectively. NATIONWIDE OR 
LOCAL TARGETING IS AVAILABLE!
 
You've probably seen millions of email addresses 
on CD's for $50 or lots of companies offering
deals that seem too good to be true...
Well, they are! 
 
We are professional email marketers who 
take pride in our excellent customer service.
 
RATED #1 EMAIL MARKETERS IN
ENTREPRENEUR MAGAZINE
 
Get a head start on your competition today 
with FREE ADVERTISING CONSULTING from 
Genius Marketing Strategies.
 
Reply to mailto:[e-mail] 
Please include:  (All info is required for a response)
Name:
e-mail address:
Phone#
Web site address:
Best time to reach:
Preferred to be contacted by EMAIL or PHONE

We accept:
VISA, MASTER CARD, AND AMERICAN EXPRESS
OR CHECK BY FAX OR PHONE.

*******************************************************
Please remove at:
mailto:[e-mail]?subject=remove
*******************************************************





Received: by ns.secondary.com (8.9.3/8.9.3) id OAA04426 for ietf-smime-bks; Thu, 15 Jun 2000 14:35:50 -0700 (PDT)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA04422 for <[e-mail]>; Thu, 15 Jun 2000 14:35:49 -0700 (PDT)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.5); Thu, 15 Jun 2000 14:34:59 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2650.21) id <JKLWYAPY>; Thu, 15 Jun 2000 14:34:59 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: draft-ietf-smime-idea-03
Date: Thu, 15 Jun 2000 14:34:52 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 1557938938068-01-01
Content-Type: text/plain;  charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

And just to be clear, this absolutely must be fixed (either the text must be
corrected to say that the parameters are encoded as ASN.1 NULL or the
examples must be corrected as I have pointed out).  The MUSTS in the current
draft are contradictory.

Blake

-----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Monday, June 12, 2000 1:22 AM
To: [e-mail]
Subject: RE: draft-ietf-smime-idea-03


This has not been taken care of in the -04 draft.

jim

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Blake Ramsdell
Sent: Friday, April 14, 2000 4:04 PM
To: '[e-mail]'; [e-mail]
Subject: RE: draft-ietf-smime-idea-03


Agree.  I think this should be 300D at the beginning, and trim the last two
bytes off of both examples.

Blake

-----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Friday, April 14, 2000 12:35 AM
To: [e-mail]
Subject: draft-ietf-smime-idea-03


The S/MIME Capability sequences appear to be wrong.  In section 4 paragraph
2,
the text states that the parameters field must be absent, however the
encoding
sequence given has the parameters encoded as NULL.  The same is true in
paragraph
3 of the same section.

jim
http://www.nwlink.com





Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA10125 for ietf-smime-bks; Thu, 15 Jun 2000 02:23:41 -0700 (PDT)
Received: from wssone.bj.co.uk (wssone.bj.co.uk [194.72.164.250]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA10120 for <[e-mail]>; Thu, 15 Jun 2000 02:23:35 -0700 (PDT)
Received: from 194.72.164.27 by wssone.bj.co.uk with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.3); Thu, 15 Jun 00 10:35:22 +0100
X-Server-Uuid: 1407cc62-e1e1-11d2-808b-0060971f0dc2
Received: by BJEX1 with Internet Mail Service (5.5.2448.0) id <MC4C4HRD>; Thu, 15 Jun 2000 10:15:29 +0100
Message-ID: <608D67882786D211B1070090271E4CB990AC51@BJEX1>
From: "Alan Shepherd" <[e-mail]>
To: "'Frank W. Nolden'" <[e-mail]>
cc: "ietf-smime" <[e-mail]>
Subject: RE: Does Slime works fine with Windows 2000 PKI
Date: Thu, 15 Jun 2000 10:15:19 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
X-WSS-ID: 15567CD0147430-01-01
Content-Type: text/plain;  charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'm jumping in too!  I'd like to add that we have deployed the MaxWare LDAP
proxy server for just this role in a large corporate in the UK.  They have a
PKI and wish to communicate externally using certificates from it, so we use
the MaxWare software to control access to the directory information,
specifically only allowing searches on mail addresses and the retrieval of
certificates.  This means that all other information in the corporate
directory is still secure.

Alan Shepherd.


> -----Original Message-----
> From: Frank W. Nolden [mailto:[e-mail]]
> Sent: 11 May 2000 16:17
> To: Walter Williams; Laurent Deffranne
> Cc: ietf-smime
> Subject: Re: Does Slime works fine with Windows 2000 PKI
> 
> 
> Sorry for jumping into this discussion, which I find very 
> interesting. There
> is a way of publishing certificates to the outside world 
> without opening up
> the AD. I think Walter mentioned in already and that is 
> replicating only the
> certificate information (with some minor additional information like
> emailaddress, distinguished name, surname, tc) to an (LDAP) 
> directory that
> is connected to the internet. Replicating this information 
> cannot be done
> using the standard X.500 DISP protocol since Microsoft does 
> not support
> that, but you can use LDIF files and other more sophisticated 
> tools like our
> MaXware Directory Sync Engine. You could put LDAP proxy 
> servers (MaXware
> also has these available as Innosoft does) in front of that 
> for security
> purposes and attribute mapping.
> 
> A major advantage is that you do not permit anyone in real 
> time either via a
> proxy or not to access information in the AD. An extra (LDAP) 
> directory is
> an extra security barrier to your AD and it will only publish the
> information you want to be available on the web, without 
> risking access to
> your AD and without configuring the Access Control in AD.
> Regards,
> 
> Frank Nolden
> 
> 
> 
> ----- Original Message -----
> From: "Walter Williams" <[e-mail]>
> To: "Laurent Deffranne" <[e-mail]>
> Cc: "ietf-smime" <[e-mail]>
> Sent: Thursday, May 11, 2000 15:57
> Subject: RE: Does Slime works fine with Windows 2000 PKI
> 
> 
> > Active directory would expose a significant amount of 
> information you
> might
> > not want the external world to know, such as a complete 
> listing of all
> your
> > w2k computers and their roles in your network.  You could 
> use a LDAP proxy
> > server to provide what you want to the internet and keep the data in
> active
> > directory.  Innosoft (Now purchased by IPlanet) makes such 
> a product.
> There
> > are probably others on the market.
> >
> > > -----Original Message-----
> > > From: Laurent Deffranne [mailto:[e-mail]]
> > > Sent: Thursday, May 11, 2000 9:48 AM
> > > To: walter.williams
> > > Cc: ietf-smime
> > > Subject: RE: Does Smime works fine with Windows 2000 PKI
> > >
> > >
> > > What would happen if you want to open the directory to anonymous
> > > access to the Web ?
> > > In such a way that you could exchange S/MIME certs with 
> outside people ?
> > >
> > >
> > >
> > >
> > >
> > >
> > > walter.williams%genuity.com@Internet
> > > 11/05/2000 15:35
> > > To: Laurent Deffranne/GKBCCB@GKBCCB
> > > cc: ietf-smime%imc.org@Internet
> > >
> > > Subject: RE: Does Smime works fine with Windows 2000 PKI
> > >
> > > Let me take the points one at a time and inline:
> > >
> > > > -----Original Message-----
> > > > From: Laurent Deffranne [mailto:[e-mail]]
> > > > Sent: Thursday, May 11, 2000 9:19 AM
> > > > To: walter.williams
> > > > Cc: ietf-smime
> > > > Subject: RE: Does Smime works fine with Windows 2000 PKI
> > > >
> > > >
> > > > Walt,
> > > >
> > > > Do you mean that there are difficulties to access 
> through LDAP an
> > > > Active Directory, as you want to read or use X509 certificates ?
> > > >
> > >
> > > No.  However, are you going to open your active directory to
> > > anonymous LDAP
> > > queries over the Internet?  If not, are you limiting S/MIME to
> > > internal use
> > > only?  If not then you are somewhat back to square one.
> > >
> > > > By the way,does somebody know issues about Active 
> Directory LDAP,
> > > > or issues to read a certificate in an Active Directory ?
> > >
> > > This worked just fine for us here, but the problem we had 
> with AD was
> that
> > > it does not support inetOrgPerson, and thus can't easily be
> > > synched up with
> > > most external LDAP directories.  You'll find you'll want 
> a metadirectory
> > > connector to synch it with any external directory.  
> Again, this is not
> an
> > > issue if you're willing to directly expose AD to internet use.
> > > >
> > > > For me it would be a mistake to use now the "brand new" Active
> > > > Directory, but if someone could tell me where I can find proofs
> > > > of lack of compatibility (from Microsoft, there must be surely
> > > > one of two), this would interrest me.
> > > >
> > > AD seems to work just fine, if you don't mind working with
> > > something with a
> > > proprietary schema.  Any LDAP and S/MIME aware client we 
> pointed at it
> > > understood the contents just fine, so the schema does not 
> seem to impact
> > > client interoperability.
> > >
> > > > Laurent
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > walter.williams%genuity.com@Internet
> > > > 11/05/2000 14:54
> > > > To: Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet
> > > > cc:
> > > >
> > > > Subject: RE: Does Smime works fine with Windows 2000 PKI
> > > >
> > > > Laurent;
> > > >
> > > > Yes, certs issued from a W2K CA can be used for S/MIME, and no
> > > > less so than
> > > > certs issued from Baltimore, Iplanet or any other CA vendor or
> > > > product.  The
> > > > main issue is not will they work, but will you be able 
> to validate the
> > > > certs.  Unless the person issuing the cert from W2K has
> > > provided you with
> > > > their server's cert, or they have certified their CA with the
> > > signature of
> > > > the publicly known CAs you will not be able to easily verify
> > > the signature
> > > > to its source.  This is not the most technically acurate way of
> > > > saying this
> > > > but I'm not awake yet.  Baltimore has preregistered 
> there CA with the
> > > > vendors distributing products, as has Verisign, Thaught, and
> > > many others.
> > > > Just make certain that you have the certificates for the W2K CA,
> > > > and access
> > > > to its revocation list so you can validate properly and 
> you'll be
> fine.
> > > >
> > > > Walt Williams
> > > > TSD-Systems
> > > > Senior IT Analyst
> > > > Genuity
> > > > www.genuity.com
> > > >
> > > > Please note: GTE Internetworking is now Genuity.
> > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail]
> > > > > [mailto:[e-mail]]On Behalf Of 
> Laurent Deffranne
> > > > > Sent: Thursday, May 11, 2000 5:45 AM
> > > > > To: ietf-smime
> > > > > Subject: Does Smime works fine with Windows 2000 PKI
> > > > >
> > > > >
> > > > > Hi everybody,
> > > > >
> > > > > Just a question :
> > > > >
> > > > > Is there any known issues using S/MIME with 
> Win2000PKI-certificates
> ?
> > > > > More generally, are Win2000 certificates usable with (and
> > > > > understood by ) the others mailers (especially Lotus Notes,
> > > > > Netscape, Eudora +plug-in?)
> > > > >
> > > > > Isn't Baltimore Unicert a "better choice" due to its greater
> > > > > compatibility ?
> > > > >
> > > > > Any advices are welcome.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Laurent Deffranne
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> 
> 

------------------------------------------------------------------------------------------
This message is for the named person’s use only.  It may contain confidential, proprietary or legally privileged information.  No confidentiality or privilege is waived or lost by any mistransmission.  If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender.  You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. PROTEK Network Management Group and each of its subsidiaries reserve the right to monitor all e-mail communications through its networks.  Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity.






Received: by ns.secondary.com (8.9.3/8.9.3) id UAA11597 for ietf-smime-bks; Mon, 12 Jun 2000 20:27:54 -0700 (PDT)
Received: from mail.harbourring.com.hk ([210.176.103.61]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA11592 for <[e-mail]>; Mon, 12 Jun 2000 20:27:50 -0700 (PDT)
Message-Id: <[e-mail]>
Received: from host [38.26.242.148] by mail.harbourring.com.hk with ESMTP (SMTPD32-4.04) id AC2A95029E; Tue, 13 Jun 2000 11:23:38 +0800
From: "Tommy Davis" <[e-mail]>
Subject: Disaster Recovery Planning #67A1
To: recove30c
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3
Mime-Version: 1.0
Date: Mon, 12 Jun 2000 22:42:05 -0500
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id UAA11593
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>

Business continuity and disaster recovery planning has now 
been made easier than ever with Version 7.3 of the 
Disaster Recovery System (DRS) product.  DRS provides a 
plan for inaccessibility or inoperability (a disaster situation).  

DRS is an industry standard software product, used by thousands 
worldwide.  DRS users are in large and small companies across 
a wide variety of industries. 

DRS conforms to federal regulations and meets insurance, auditing 
and legal requirements.  DRS runs under Windows, with stand-alone 
and network versions available.  DRS provides the most complete, 
easy-to-use product available today.

To prove its value, a free trial is available.  For more 
information, visit our web site at 
www.drsbytamp.com <http://www.drsbytamp.com>.   
Dealer and distributor inquiries are welcomed

*****************************************************************
This message is sent in compliance of the new email bill
section 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618,
further transmissions to you by the sender of this email may be
stopped at no cost to you. This message is not intended for
residents in the State of WA, CA & VA Screening of addresses
has been done to the best of our technical ability.If you are a 
Washington, Virginia, or California resident please remove
yourself.
====================================================

///////////////////////////////////////////////////
To be removed permanantly from this list reply to:
mailto:[e-mail]?subject=remove
///////////////////////////////////////////////////





Received: by ns.secondary.com (8.9.3/8.9.3) id BAA24681 for ietf-smime-bks; Mon, 12 Jun 2000 01:22:32 -0700 (PDT)
Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA24677 for <[e-mail]>; Mon, 12 Jun 2000 01:22:30 -0700 (PDT)
Received: from jimsch1t (ip171.du1.bel.nwlink.com [209.20.136.171]) by smtp.nwlink.com (8.9.3/8.9.3) with ESMTP id BAA04279 for <[e-mail]>; Mon, 12 Jun 2000 01:21:53 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>
Subject: RE: draft-ietf-smime-idea-03
Date: Mon, 12 Jun 2000 01:22:18 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
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 has not been taken care of in the -04 draft.

jim

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Blake Ramsdell
Sent: Friday, April 14, 2000 4:04 PM
To: '[e-mail]'; [e-mail]
Subject: RE: draft-ietf-smime-idea-03


Agree.  I think this should be 300D at the beginning, and trim the last two
bytes off of both examples.

Blake

-----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Friday, April 14, 2000 12:35 AM
To: [e-mail]
Subject: draft-ietf-smime-idea-03


The S/MIME Capability sequences appear to be wrong.  In section 4 paragraph
2,
the text states that the parameters field must be absent, however the
encoding
sequence given has the parameters encoded as NULL.  The same is true in
paragraph
3 of the same section.

jim
http://www.nwlink.com




Received: by ns.secondary.com (8.9.3/8.9.3) id MAA05505 for ietf-smime-bks; Fri, 9 Jun 2000 12:47:14 -0700 (PDT)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05500 for <[e-mail]>; Fri, 9 Jun 2000 12:47:12 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com (dial04.spyrus.com [207.212.34.124]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id MAA28172 for <[e-mail]>; Fri, 9 Jun 2000 12:55:08 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 09 Jun 2000 08:36:23 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: draft-ietf-smime-idea-04.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear Draft Authors:

The Working Group Last Call is almost finished (it closes on Monday).  I 
wanted to post the things that I noticed in the document that I have not 
seen posted by anyone else.

In section 2, the document says:

    The identifier's parameters field contains the initial
    vector IV as an optional parameter.

      IDEA-CBCPar ::= SEQUENCE {
        IV  OCTET STRING OPTIONAL -- exactly 8 octets }

    If IV is specified as above, it MUST be used as initial vector. In
    this case, the ciphertext MUST NOT include the initial vector. If
    IV is not specified, the first 64 bits of the ciphertext MUST be
    considered as the initial vector. However, this alternative of not
    including the IV SHOULD NOT be applied in S/MIME.

First, please change "initial vector IV" to "initialization vector (IV)" or 
"initialisation vector (IV)" depending on you geographic preference (US 
English vs. UK English).  Then, use IV throughout.

Second, we have already seen messages requesting the removal of the 
SEQUENCE wrapper in the ASN.1.  This should be done.  The OPTIONAL is not 
needed either.  In the AlgorithmIdentifier structure, the parameter is 
already OPTIONAL.  I suggest:

       IDEA-CBC-IV  ::=  OCTET STRING  -- exactly 8 octets

Third, I would like to see the final sentence in the last paragraph 
reworded.  I suggest:

    However, the IV MUST be included in the AlgorithmIdentifier parameter
    when IDEA is used with CMS.

Later in section 2, the document says:

    The identifier's parameters field MUST be NULL.

Many algorithms use this technique.  Since the AlgorithmIdentifier 
parameters are OPTIONAL, the same semantics can be provided with fewer bits 
on the wire by requiring that the parameters field be absent.  Please 
consider this alternative.

In section 3.1, step 3, there is a typo.  Please change ":=" to "=".

Thanks for your attention,
   Russ


Received: by ns.secondary.com (8.9.3/8.9.3) id MAA05796 for ietf-smime-bks; Thu, 8 Jun 2000 12:58:10 -0700 (PDT)
Received: from rgaexconn.rgare.com ([198.190.171.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05792 for <[e-mail]>; Thu, 8 Jun 2000 12:58:08 -0700 (PDT)
Received: by RGAEXCONN with Internet Mail Service (5.5.2650.21) id <M356W79H>; Thu, 8 Jun 2000 15:05:59 -0500
Message-ID: <E1854B2D3D19D311A2CD0090274F974701C8C650@RGAEXCVS>
From: "Hellrung, Lisa" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: 
Date: Thu, 8 Jun 2000 15:05:54 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Erik,

I changed the second message to opaque-signed and removed the second
header
but still no getting a security warning that the message has been
tampered
with.

"Content-Type:
application/pkcs7-mime;smime-type=opaque-signed;name=smime.p7m" + vbCrLf
"Content-Transfer-Encoding: base64" + vbCrLf
"Content-Disposition: attachment;" + vbCrLf + "
filename=""smime.p7m"""
+ vbCrLf + vbCrLf
Encoded message

Any other ideas on how to make this work? Thanks.

Lisa


----- Original Message -----
From: "Erik Neuenschwander" <[e-mail] <mailto:[e-mail]>>
To: "Hellrung, Lisa" <[e-mail] <mailto:[e-mail]>>
Sent: Thursday, June 08, 2000 2:16 PM
Subject: Re: Signed message


> This should be opaque-signed, the second kind, the kind that you say
gives
> you errors. How does this one turn out?
>
> see my one inline comment
>
> ----- Original Message -----
> From: "Hellrung, Lisa" <[e-mail] <mailto:[e-mail]>>
> To: <[e-mail] <mailto:[e-mail]>>
> Sent: Thursday, June 08, 2000 11:52 AM
> Subject: Signed message
>
>
> > I was wondering if someone could help me out with the syntax of a
signed
> > message? I am able to send signed and encrypted e-mail but if I only
> sign
> > that e-mail, it will either show up in Outlook and Outlook Express
as a
> > regular message or signed but "Message has been tampered with"
error.
> >
> > When sent with
> >
> > "Content-Type: multipart/signed;
> protocol="application/x-pkcs7-signature";
> > micalg=SHA1;
> > boundary="=====NextPart_qaNWAwffsV5PxkAy7ndv"
> >
> > Message
> >
> > "Content-Type: application/x-pkcs7-signature;" + vbCrLf + "
> > name=""smime.p7s""" + vbCrLf
> > "Content-Transfer-Encoding: base64" + vbCrLf
> > "Content-Disposition: attachment;" + vbCrLf + "
> > filename=""smime.p7s""" + vbCrLf + vbCrLf
> > Encoded signed message
> >
> > It appears as a normal mail message.
> >
> > When sent with
> >
> > "Content-Type:
> application/pkcs7-mime;smime-type=signed-data;name=smime.p7m"
> > + vbCrLf
> > "Content-Type: application/pkcs7-mime;" & vbCrLf + "
> > name=""smime.p7m""" + vbCrLf
> ^^^^^^^^^^^^
> Where is this second Content-Type header coming from?
>
> > "Content-Transfer-Encoding: base64" + vbCrLf
> > "Content-Disposition: attachment;" + vbCrLf + "
> filename=""smime.p7m"""
> > + vbCrLf + vbCrLf
> > encoded message
> >
> > It appears as signed but invalid because message has been tampered
with.
> >
> >
> > If anyone could help me to correct this problem, I would greatly
> appreciate
> > it.
> >
> > Also, the first message works when later encrypted. Thanks.
> >
> >
>




Received: by ns.secondary.com (8.9.3/8.9.3) id LAA04528 for ietf-smime-bks; Thu, 8 Jun 2000 11:44:54 -0700 (PDT)
Received: from rgaexconn.rgare.com ([198.190.171.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA04524 for <[e-mail]>; Thu, 8 Jun 2000 11:44:53 -0700 (PDT)
Received: by RGAEXCONN with Internet Mail Service (5.5.2650.21) id <M356W7BV>; Thu, 8 Jun 2000 13:52:38 -0500
Message-ID: <E1854B2D3D19D311A2CD0090274F974701C8C64F@RGAEXCVS>
From: "Hellrung, Lisa" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Signed message
Date: Thu, 8 Jun 2000 13:52:32 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I was wondering if someone could help me out with the syntax of a signed
message? I am able to send signed and encrypted e-mail but if I only sign
that e-mail, it will either show up in Outlook and Outlook Express as a
regular message or signed but "Message has been tampered with" error. 

When sent with 

"Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
micalg=SHA1; 
boundary="=====NextPart_qaNWAwffsV5PxkAy7ndv"

Message

"Content-Type: application/x-pkcs7-signature;" + vbCrLf + "
name=""smime.p7s""" + vbCrLf
"Content-Transfer-Encoding: base64" + vbCrLf
"Content-Disposition: attachment;" + vbCrLf + "
filename=""smime.p7s""" + vbCrLf + vbCrLf
Encoded signed message

It appears as a normal mail message.

When sent with

"Content-Type: application/pkcs7-mime;smime-type=signed-data;name=smime.p7m"
+ vbCrLf
"Content-Type: application/pkcs7-mime;" & vbCrLf + "
name=""smime.p7m""" + vbCrLf
"Content-Transfer-Encoding: base64" + vbCrLf
"Content-Disposition: attachment;" + vbCrLf + "      filename=""smime.p7m"""
+ vbCrLf + vbCrLf
encoded message

It appears as signed but invalid because message has been tampered with.


If anyone could help me to correct this problem, I would greatly appreciate
it. 

Also, the first message works when later encrypted. Thanks.



Received: by ns.secondary.com (8.9.3/8.9.3) id JAA28608 for ietf-smime-bks; Thu, 8 Jun 2000 09:08:26 -0700 (PDT)
Received: from mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA28598 for <[e-mail]>; Thu, 8 Jun 2000 09:08:24 -0700 (PDT)
From: [e-mail]
Received: from zainprov ([207.193.24.81]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <[e-mail]> for [e-mail]; Thu,  8 Jun 2000 11:06:02 -0500 (CDT)
Date: Thu, 08 Jun 2000 11:06:02 -0500 (CDT)
Date-warning: Date header was inserted by mta5.rcsntx.swbell.net
Subject: Shocking LOSE 10-100lbs. DESTINY
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=unknown-8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello From Destiny,

You will LOOSE 20-100 pounds easy!
Do to Such a high demand for Destiny, we are able
To Dramatically reduce our price for the entire System!
You will LOVE our incredible offer on this
Scientific Breakthrough in Weight Loss.
Now with a 105% Money Back Guarantee!   
LOOK! http://home.swbell.net/zainprov/destiny.htm



We hope things are going well for you.  Good luck, God Bless, and 
HAVE A GREAT DAY!



Either you are someone else subscribed to our list.  To be removed
Simply reply with a blank email.  

Thank you,

Sherry Wilson



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id WAA29457 for ietf-smime-bks; Wed, 7 Jun 2000 22:37:22 -0700 (PDT)
Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA29453 for <[e-mail]>; Wed, 7 Jun 2000 22:37:20 -0700 (PDT)
Received: from jimsch1t (ip191.du1.bel.nwlink.com [209.20.136.191]) by smtp.nwlink.com (8.9.3/8.9.3) with ESMTP id WAA24681; Wed, 7 Jun 2000 22:45:37 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
Subject: RE: Cert Dist Changes
Date: Wed, 7 Jun 2000 22:46:03 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
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 David P. Kemp
> Sent: Friday, June 02, 2000 7:52 AM
> To: [e-mail]
> Subject: RE: Cert Dist Changes
>
>
>
> > From: "Jim Schaad" <[e-mail]>
> > To: "David P. Kemp" <[e-mail]>, <[e-mail]>,
> <[e-mail]>
> > Subject: RE: Cert Dist Changes
> > Date: Thu, 1 Jun 2000 21:34:34 -0700
> >
> > I am a bit loss for words.  Are you saying that data is to
> appear in one and
> > only one location in the directory and not to be duplicated?
> If this is not
> > the case then I don't see your problem although consistancy can
> be a problem
> > depending on the different tools used to update the directory
> for different
> > purposes.  (A mail program publishing information vs an access control
> > program (such as the Win2K directory might not keep/correctly update all
> > fields.)
> >
> > There is nothing that does not let you put things into the
> userCertificate
> > and caCertificate fields, however many programs only update the
> > userCertificate field at present.  The code that I wrote while
> at Microsoft
> > would publish into both the userSMimeCertificate and
> userCertificate fields
> > but ignored the caCertificate field as this exists only on CAs.
>  This means
> > that if a user publishes a certificate in a different directory
> (possibly
> > unaccessable) directory, the client has no way of getting to CA
> > certificates, thus for the general case caCertificates is unuseful.
>
>
> Jim,
>
> That is precisely the situation (CA certificates not being accessible
> to all consuming applications) I think we should be trying to avoid.
>
> If you start with a directory environment where caCertificate is not
> useful, and you want to allow a particular application (S/MIME) to
> operate, you have two possible courses of action:
>
> 1) encourage directory administrators to make caCertificate useful, or
> 2) encourage directory administrators to populate an S/MIME-specific
>    attribute to bypass the need for caCertificate.
>
> I believe that option 2 is harmful to the Internet environment.
> Once administrators have made the effort to populate a repository with
> certificates, the identical repository should be usable by S/MIME, SSL,
> IPsec, and other applications.  Developing a stovepipe (single-purpose)
> solution is easier in the short run, but will cost us dearly later.
>
> Regards,
> Dave
>

Dave,

If this is what you believe, I encourage you to immeadiately put a draft of
some type in the PKIX working group that will allow me to do path discovery
in a non-X509 directory environment (the internet) where all information
currently in the certificate is X509 based.  When I have looked that the
problem I have come to the conclusion that the problem is not solvable in
the general case given: 1) X509 certificates are based on X509 names but
directory lookup is not for non-X509 directories.  2) Attempting to identify
the directory that needs to be used for doing the lookup is not presently
doable (what is the LDAP directory that I should use for c=us, o=missi).
CRLs may be found though the CDP, but certificates cannot be found from the
DN.

jim



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id WAA29449 for ietf-smime-bks; Wed, 7 Jun 2000 22:37:17 -0700 (PDT)
Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA29445 for <[e-mail]>; Wed, 7 Jun 2000 22:37:14 -0700 (PDT)
Received: from jimsch1t (ip191.du1.bel.nwlink.com [209.20.136.191]) by smtp.nwlink.com (8.9.3/8.9.3) with ESMTP id WAA24675; Wed, 7 Jun 2000 22:45:34 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "Sharon Boeyen" <[e-mail]>, <[e-mail]>
Subject: RE: SMIME cert dist draft and X.509
Date: Wed, 7 Jun 2000 22:46:00 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
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>

Sharon,

There were a number of limitations that are in X509 that I was trying to
overcome with this draft:

The supportedAlgorithms field was not used for two reasons, first I did not
know about it when this started and secondly attribute certificates were not
defined at the time the problem was addressed, thus they were not a part of
every S/MIME application already.  The use of the SignedData structure means
that we are re-using already existing code in every S/MIME application.
(The exact same mechinism is used for transfering the information when
sending a signed message between two entities.)

Given that we are living in an LDAP world rather than an X509 world, using
isser DNs of certificates to attempt to find an issuer certificate is an
extremely difficult problem.  Add to this the questions of
companies/individuals not publishing intermeadiate CA certificates or making
them private (although the CRL might be available from a non-directory
location) and I don't know that in the internet world that the certificate
retrevial portion of path construction is viable.

While I agree that this problem might have been better considered in the
PKIX working group as the problem is universion, however the problem and the
solution was first found by S/MIME developers and the chair of the group
agreed that it was a reasonable problem to be put before the group.
Additionally, the solution used some items that were defined by the working
group in the S/MIME documents rather than in PKIX documents.  Lastly, the
PKIX group is still very X509 directory centric in many of it's solutions
while the S/MIME working group is extremely LDAP centric.  Thus what seems
to be a problem for the S/MIME working group might not be a problem for the
PKIX working group (such as finding CA certificates without an X509
directory).

Additionally please note that we have not solved the general path
construction problem, we have only made it easier (since the holder of the
certificate is in a better situation to build their own path) for the sender
to avoid the problem.  In the event that the PKIX group came up with a
viable method of doing path discovery then this draft can be revised so that
the full path information was not required in the attribute even though
there are situations (i.e. offline or non-directory location of the
attribute) where it might be useful.

jim schaad

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Sharon Boeyen
Sent: Friday, June 02, 2000 11:42 AM
To: '[e-mail]'
Subject: SMIME cert dist draft and X.509



I am not a regular participant on this mailing list, and therefore lack the
history behind this draft. However, as editor of X.509, I'm wondering why
this draft invents new data structures for requirements that, after a very
quick review, I think that X.509 already has standardized structures to
support. From a 509 perspective, I certainly want to understand any
shortcomings that specification has with respect to meeting the needs of the
applications that use public-key certificates.

Regarding SMimeCapabilities themeselves; was the supportedAlgorithms
attribute from 509 considered? If so, were there specific shortcomings that
it had? Note that it is defined in X.509 as an attribute. Attributes can be
stored in
directories as part of entries (with or without being digitally signed
and/or encrypted), they can be transferred in application protocols, they
can be included in public-key and attribute certificates.

Regarding the requirement to tie a set of supported algorithms to a specific
certificate; the construct defined in the Internet draft is semantically an
attribute certificate. Was an X.509 attribute certificate considered and
rejected? If so, what were its deficiencies? Note that there are a number of
ways to identify the holder of an X.509 attribute certificate. One of those
is the hash of a public-key certificate. An attribute certificate that
contained the hash of a public-key certificate and the supportedAlgorithms
attribute seems to provide the functionality you're looking for. If you want
a construct that includes several iterations (i.e.  the set of algorithms
for each public-key certificate), then the X.509 construct
attributeCertificateAttribute seems to provide this because it is a
multivalued attribute that contains values of the attributeCertificate
construct. Again, these can be stored in directories, stored in files,
transferred in application protocols etc.

Regarding PKI path construction; this is an area where a number of different
groups seem to be active. I'm curious why there would be an smime specific
mechanism for this anyway, when if there really is a problem, its probably
not unique
to smime. PKIX seems like a better place to solve this problem. I'm not sure
I really understand your proposed solution. Are you focused only on
hierarchies or also addressing networked trust models? Why store the path
with the subject's domain when its the relying party's domain where the
information is needed. Why associate it with a user certificate at all,
since the same path (less the user cert) can be reused for any user certs
signed by the same CA? X.509 has a standard attribute called pkiPath that I
think may satisfy the requirement. This attribute contains a sequence of
CA-certificates and its intent is that it stores paths that are frequently
used by the relying parties within the community of a given CA. As such, it
can be used to reduce the number of network connections and directory (or
other protocol) requests to external domains. It is intended to be an
optional facility that may be useful in some environments, but not necessary
in others.

With respect to all of these, my view is that, if directories are being used
as repositories for the information, then ALL public-key certificates issued
to a user be stored in the userCertificate attribute of their directory
entry. This eliminates the need for specialized application-specific tools
on the relying party side to find application specific data. If there are
enhanced mechansims that provide potential efficiencies in an application
specific environment these
should be optional enhancements and not eliminate the fundamental
interoperability requirement to store information in a common place. I hold
the same view with respect to the pkiPath attribute. If stored in a
directory it should not eliminate the need to store information as defined
in X.509 and profiled by PKIX in the crossCertificatePair and caCertificate
attributes.

I apologize in advance if, due to my lack of knowledge of the history of
this spec, I'm asking questions that have been previously dealt with and
closed, but felt I should at least ask, in the capacity of X.509 editor.

FYI, if anyone needs to see the X.509 spec, they can obtain it in Word or
pdf format from the following:

ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/

This text has been approved by ITU and is the 2000 edition of X.509,
although many of things I mention were in the 1997 3rd edition text as well.


Sharon

Sharon Boeyen
Entrust Technologies
[e-mail]



Received: by ns.secondary.com (8.9.3/8.9.3) id WAA06464 for ietf-smime-bks; Mon, 5 Jun 2000 22:33:06 -0700 (PDT)
Received: from gate2.healthware.on.ca ([209.167.93.99]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA06455 for <[e-mail]>; Mon, 5 Jun 2000 22:33:05 -0700 (PDT)
Message-Id: <[e-mail]>
Received: from host ([63.21.182.114]) by gate2.healthware.on.ca (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id ca; Mon, 5 Jun 2000 20:03:36 -0400
From: "Archie Reed" <[e-mail]>
Subject: Desktop Artwork For Your Computer !
To: art38d
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3
Mime-Version: 1.0
Date: Mon, 05 Jun 2000 19:12:30 -0500
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id WAA06458
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>

http://www.shoopdogg.com/sdgcd/sdgcd.html
 
More than just Wallpaper. The ShoopDogg Graphics 
CD-Rom takes it to a new evel.  Illustrated Desktop 
Art. Is there a way to wake up every orning o a new 
Desktop Wallpaper Celebrity for your computer? Now 
there is.

http://www.shoopdogg.com/sdgcd/sdgcd.html

Desktop Illustrations as seen on Sung Hi Lee, Kaila Yu,
Linda Tran, & Sae arks web sites to mention a few.
 
Over 60 inter-net models to view. Hundreds of Illustrated Desktop
Wallpaper.
 
Plus, many surreal world Illustrations and artwork.
 
Click Here To Get Sample http://www.shoopdogg.com/sdgcd/sdgcd.html

 
*********************************************************
You can have your address removed from our database by
replying to:
mailto:[e-mail]?subject=remove
*********************************************************








Received: by ns.secondary.com (8.9.3/8.9.3) id GAA11976 for ietf-smime-bks; Mon, 5 Jun 2000 06:11:28 -0700 (PDT)
Received: from rmx470-mta.mail.com (rmx470-mta.mail.com [165.251.48.48]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA11972 for <[e-mail]>; Mon, 5 Jun 2000 06:11:26 -0700 (PDT)
Received: from web622-wrb.mail.com (web622-wrb.mail.com [165.251.33.62]) by rmx470-mta.mail.com (8.9.3/8.9.3) with SMTP id JAA03785 for <[e-mail]>; Mon, 5 Jun 2000 09:19:36 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 5 Jun 2000 09:19:32 -0400 (EDT)
From: Erynn Schmidt <[e-mail]>
To: [e-mail]
Subject: s/mime v2 vs. v3
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: mail.com
X-Originating-IP: 192.91.146.35
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>

Hello

I'm researching the differences between S/MIME v2 and v3.  I was wondering
if there was a paper that had these differences listed.  Any help would be
greatly appreciated.

Thanks
Erynn



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA01801 for ietf-smime-bks; Sun, 4 Jun 2000 14:50:37 -0700 (PDT)
Received: from hal9000.vguard.com (vguard.com [192.117.162.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA01792 for <[e-mail]>; Sun, 4 Jun 2000 14:50:27 -0700 (PDT)
Received: by vguard.com with Internet Mail Service (5.5.2650.21) id <L0NAAK2Z>; Mon, 5 Jun 2000 00:58:52 +0200
Message-ID: <[e-mail]>
From: Raviv Karnieli <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Final 29 March 2000 S/MIME WG Minutes
Date: Mon, 5 Jun 2000 00:58:49 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John,

I was looking for Greg's briefing which was supposed to be stored at
ftp://ftp.ietf.org/ietf/smime/  but could not find it. Can you point it out
to me?


Thanks,

Raviv Karnieli - CTO
Vanguard Security Technologies Ltd.
Tel. [phone]       Fax [phone]
www.vguard.com             [e-mail]

This message left my computer secured since I'm using 
MAILguardian Enterprise the first true end to end enterprise e-mail security
solution that is policy based, centrally managed and totally transparent to
the end users.

You can get your own free evaluation copy of MAILguardian 
at http://www.vguard.com/prod.asp



-----Original Message-----
From: Pawling, John [mailto:[e-mail]]
Sent: Monday, May 08, 2000 10:51 PM
To: SMIME WG (E-mail)
Subject: Final 29 March 2000 S/MIME WG Minutes



This message includes the minutes of the IETF S/MIME Working Group
meeting held on 29 March 2000 in Adelaide, Australia.  All briefing
slides will be stored at: ftp://ftp.ietf.org/ietf/smime/.  These
minutes include comments from the briefing presenters.  
Reported by John Pawling.

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

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

Introductions				Russ Housley
Working Group Status			Russ Housley
Security Policies and Labels		Russ Housley
CERTDIST Draft Discussion 		Jim Schaad
Symmetric Key Distribution		Sean Turner
DOMSEC Draft Discussion 		Bill Ottaway
Interoperability Matrix 		Jim Schaad
CMS/ESS Examples				Paul Hoffman
Crypto Algorithm Documents		Russ Housley
E-mail Addresses & Certificates	Greg Colla
S/MIME Freeware Library			John Pawling
Electronic Signature Formats		John Ross
Wrap up					Russ Housley

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

S/MIME Working Group Status - Russ Housley

Russ outlined the strategy for advancing the following RFCs from
Internet Proposed Standards to Internet Draft Standards:
RFC 2630  Cryptographic Message Syntax, R. Housley, June 1999
RFC 2631  Diffie-Hellman Key Agreement Method, E. Rescorla, June 1999
RFC 2632  S/MIME Version 3 Certificate Handling, B. Ramsdell, June 1999
RFC 2633  S/MIME Version 3 Message Specification, B. Ramsdell, June 1999
RFC 2634  Enhanced Security Services for S/MIME, P. Hoffman, June 1999
RFC 2785  Methods for Avoiding the "Small-Subgroup" Attacks on the
          Diffie-Hellman Key Agreement Method for S/MIME. 
          R. Zuccherato.  March 2000. [Informational]

The aforementioned documents must meet the following requirements to
become Draft Standards:
1) Meet requirements documented in RFC 2026
2) Stable, mature, and useful specification
3) At least two independent and interoperable implementations
   from different code bases
4) Draft Standards cannot reference Proposed Standard RFCs or 
   Experimental RFCs, so the aforementioned RFCs are blocked
   until the PKIX Certificate and CRL Profile "Son-of-RFC 2459"
   Internet-Draft (I-D) (draft-ietf-pkix-new-part1-01.txt) 
   progresses to Draft Standard.
 
Russ stated that Jim Schaad has developed an interoperability matrix
for RFCs 2630 through 2634.  Once completed, the matrix will 
indicate which features have and have not been implemented.  So far,
Microsoft and J.G. Van Dyke and Associates (VDA) have provided input
to the interoperability matrix.  Russ asked that other organizations
that have developed S/MIME v3 capabilities should contribute to the
matrix.     

Russ stated that testing of the example data included in the 
"Examples of S/MIME Messages" I-D is providing informal inputs for
the matrix.  Paul Hoffman stated that that other code bases also 
need to be tested.  He welcomed feedback from novice developers.  
He has offered to coordinate interoperability testing.  In the past,
Paul has coordinated face-to-face SecureConnect interoperability
events.  He believes that future interoperability testing will not
be face-to-face, but will be supported via a bulletin board or e-mail.
He will announce any S/MIME inter events on the S/MIME WG mail list.
Those events will be discussed in detail on the S/MIME developers 
mail list <[e-mail]>

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

Mapping Company Classification Policy to the S/MIME Security Label
- Russ Housley

The "Implementing Company Classification Policy with the S/MIME 
Security Label" I-D, <draft-ietf-smime-seclabel-00.txt>, December 
1999, was authored by Weston Nicolls.  It is planned that the document
will become an Informational RFC.  It describes how the ESS Security
Label can be used to implement an organizational security policy.  
It includes three organizational examples: Whirlpool, Caterpillar 
and Amoco.  One use of this document is to provide sample policies
for interoperability testing.

The document includes the security policy for Amoco Corporation
as follows: 
  - Confidentiality: General, Confidential, Highly Confidential
  - Integrity: Minimum, Medium, Maximum

It includes the security policy for Caterpillar Inc as follows: 
  - Confidentiality: Public, Confidential Green, 
        Confidential Yellow, Confidential Red

It includes the security policy for Whirlpool Corporation 
as follows: 
  - Confidentiality: Public, Internal, Confidential
  - Additional marks at discretion of owner:
    - Privacy Marks?  
    - Security Categories?
    - Do they require access control?

Way Forward:
- Support interoperability testing
- Need to assign Object Identifiers: IETF values for this document
    and testing
- Organizations assign their own

After discussion with Weston Nicolls, who could not be present at 
this meeting, three object identifiers were assigned to permit the
Whirlpool, Caterpillar and Amoco security policies to be used in 
interoperability testing.  These object identifiers are not the 
ones that will be used by the companies, rather they are 
intended for testing.  The object identifiers are:

 -- S/MIME Working Group Object Identifier Registry
    id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 
             us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }

 -- Test Security Policies Arc
    id-tsp  OBJECT IDENTIFIER ::= { id-smime 7 }

 -- Test Security Policies
    id-tsp-TEST-Amoco          OBJECT IDENTIFIER ::= { id-tsp 1 }
    id-tsp-TEST-Caterpillar    OBJECT IDENTIFIER ::= { id-tsp 2 }
    id-tsp-TEST-Whirlpool      OBJECT IDENTIFIER ::= { id-tsp 3 } 

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

CERTDIST Draft Discussion - Jim Schaad

Jim discussed the Certificate Distribution Specification I-D 
<draft-ietf-smime-certdist-04.txt>, October 20, 1999.  The CERTDIST
I-D was submitted for S/MIME WG "last call" for comments on 22 October
1999.  Jim stated that he received comments regarding the following
topics:
- LDAP Directory Attribute layout
- Additional arguments against CERTDIST Section 2 (current methods
  of publishing certificates)
- miscellaneous minor comments

Jims stated that he plans to publish an updated version of the
CERTDIST I-D soon.

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

Symmetric Key Distribution - Sean Turner

Sean discussed the S/MIME Symmetric Key Distribution I-D, 
<draft-ietf-smime-symkeydist-00.txt>, December 20, 1999.  He stated
that the design goals are to provide a transport independent
mechanism for distribution of symmetric keys to a group of users.
The mechanism must use RFC 2630.  It must maximize the reuse of
existing group/list management techniques (listserv, majordomo, etc).
Seam explained the diagrams included in the I-D.  

Sean stated that he did not know of any patents regarding the secure
distribution of symmetric keys.  He asked if anybody else knew of
any patents.  Nobody replied.

Paul Hoffman pointed out that the majordomo mail list server 
software does not support all mail list features.  He stated that
the SYMPA mail list server includes a database and rich set of 
features.

Paul also pointed out that customers ask him on a monthly 
basis for secure mail list capabilities, so he knows that there
are real requirements for these capabilities. 

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

DOMSEC Draft Discussion - Bill Ottaway

Bill presented a briefing regarding the "Domain Security Services Using
S/MIME" I-D <draft-ietf-smime-domsec-04.txt>.  He stated that there 
are minor differences between the -03 and -04 drafts as follows:
- DOMSEC signatures are now added by encapsulation only. (Used to
  allow parallel signatures). 
   - Allows order of third party signature application to be known.
   - More secure.
- Section four re-written to aid understanding

Bill discussed the proposed solution to an issue raised during the
December 1999 S/MIME WG meeting.  From those minutes: "Jim Schaad
recommended that the domain name should be exactly matched.
Jim also pointed out that RFC 2630 states that the content type 
should be id-data when there are no signers of a signedData object."
Bill proposes that the original domain naming conventions should be
preserved.  Bill briefed that the users "must always rely on the CA
to police naming conventions."

Bill addressed Jim's other comment by adding text to the case when
no originator signature is present to state that the eContentType
will be id-data as specified in CMS.  However, the eContent will
contain the unsigned message instead of being left empty as 
suggested in CMS (section 2).  This allows the DOMSEC signature 
to cover the message which does not have an originator signature.

Bill stated that an object identifier must be obtained for the
id-signatureType attribute.  He believes that the document is
ready for working group last call.

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

Interoperability Matrix - Jim Schaad

Jim developed an interoperability matrix for RFCs 2630 through 2634.
Jim has documented the features supported by Microsoft.  VDA provided
input to Jim regarding the capabilities of the S/MIME Freeware 
Library (SFL).  VDA also provided input regarding interoperability
testing conducted between the SFL and Microsoft.  Jim asked for others 
to submit input to him at [e-mail].  Jim also pointed out that
there are some minor comments/questions to the RFCs that accompany 
the matrix.
  
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Examples of S/MIME Messages - Paul Hoffman

Paul stated that the "Examples of S/MIME Messages" I-D needs more
input.  He stated that VDA had tested the samples in the document
and was planning to provide further sample data for inclusion in 
the document.  He stated that the document is valuable because it
includes the ASN.1 encoded examples.  He stated that there is sample
data that can be extracted using a Perl script that is also
included in the document.

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

S/MIME WG Cryptographic Algorithm Specification - Russ Housley

Russ briefed that the current S/MIME WG charter states: "The 
Cryptographic Message Syntax (CMS) is cryptographic algorithm 
independent, yet there is always more than one way to use any algorithm.
To ensure interoperability, each algorithm should have a specification
that describes its use with CMS.  Specifications for the use of 
additional cryptographic algorithms will be developed.  An 
additional suite of  "mandatory to implement" algorithms may be
selected."

Russ briefed that the following I-Ds document the use of crypto
algorithms with RFC 2630:
 1) Use of the CAST-128 Encryption Algorithm in CMS, 
     <draft-ietf-smime-cast-128-01.txt>
 2) CMS KEA and SKIPJACK Conventions,
     <draft-ietf-smime-cmskea-04.txt>
 3) CMS RSAES-OAEP Conventions, 
     <draft-ietf-smime-cms-rsaes-oaep-00.txt>
 4) Elliptic Curve S/MIME, 
     <draft-ietf-smime-ecc-00.txt>
 5) Incorporation of IDEA Encryption Algorithm in S/MIME
     <draft-ietf-smime-idea-02.txt>

Russ said that the following question was raised on the S/MIME WG
mail list: "Should the specifications be published as Standards 
Track RFCs or Informational RFCs?"  Russ stated that "mandatory-to-
implement" algorithms will be published as Standards Track RFCs.
He pointed out that the current S/MIME WG charter also states that
complete algorithm specifications will be published as Standards
Track RFCs.  

Jeff Schiller stated that he believes that all drafts describing
the details of a crypto algorithm must be Informational because
the IETF cannot control the definition of the crypto algorithms.
Jeff further stated that he believes that all documents describing
how crypto algorithms can be used with an IETF protocol can be
Standards Track because the IETF can control the use of the 
crypto algorithms.  He further stated that all documents describing
how secret or proprietary crypto algorithms can be used can not be
Standards Track.   

Russ applied Jeff's recommendations to the aforementioned list
of I-Ds:

 1) The "Use of the CAST-128 Encryption Algorithm in CMS" I-D can
    be a Standards Track document because the CAST 128 algorithm
    description is freely available.

 2) The "CMS KEA and SKIPJACK Conventions" I-D can not be a Standards
    Track document because the U.S. Government has not freely 
    published the description of the FORTEZZA 80-bit wrap function
    used to wrap the 80-bit SKIPJACK content encryption key.  

 3) The "CMS RSAES-OAEP Conventions" I-D can be a Standards Track 
    document because the PKCS #1 v2.0 algorithm description is 
    freely available.  

 4) The "Elliptic Curve S/MIME" I-D can be a Standards Track 
    document because the algorithms are documented in ANSI X9.62
    and ANSI X9.63.  Paul Hoffman said that someone told him that  
    Certicom has patents or pending patents on all of the "interesting
    and useful" curves.  Russ agreed that Standards Track could only
    be achieved if the appropriate patent statements were made by 
    Certicom or any other patent holder. 
    
 5) The "Incorporation of IDEA Encryption Algorithm in S/MIME" I-D 
    can not be a Standards Track document because the IDEA 
    crypto algorithm description is not freely available.

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

Application of Attribute Certificates (AC) in S/MIME - Greg Colla

Greg's briefing addressed the topic of checking the e-mail address
of the signedData signer against the e-mail address in the signer's
certificate.

Greg briefed that there are problems with binding the subject's e-mail
address with the subject's public key in an X.509 public key certificate
such as:
- Multiple e-mail addresses
- Maintenance of e-mail addresses
- Security Proxy (a proxy signs and decrypts on behalf of many users)
- Privacy/Spam

Greg briefed the following requirements:
Address Aliasing: Associate a single entity with multiple e-mail
    addresses, with a single PKC.
Secure Proxying: Associate multiple entities, each with their own
    e-mail address,  with a common PKC.
Address Sharing: Associate multiple entities, each with their own PKC,
    with a single e-mail address.

Greg proposed the following:
- Maintenance of e-mail addresses limits S/MIME usability
- ACs can be used to cryptographically bind e-mail addresses with PK
   certificates
- E-mail ACs provide a flexible solution for maintaining e-mail 
   addresses
- Supplements current infrastructure
- Localized modifications required to S/MIME components to use 
   E-mail ACs
- E-mail ACs can be used to solve other S/MIME limitations

Greg summarized by stating that his proposal provides a strategy
for removing email addresses from PK certificates.  Greg's briefing
is stored at ftp://ftp.ietf.org/ietf/smime/ and includes additional
details regarding his proposal.

Paul Hoffman stated that there are not many deployed ACs and that
most companies have not implemented ACs.  Paul stated his concern
that the AC proposal will add confusion to and delay the deployment
of S/MIME v3.  He stated that ACs can be used in the future to solve
problems.  Greg Colla rebutted that they face these problems today
(i.e. associated with binding e-mail addresses with public keys).

Jim Schaad stated the following comments/questions regarding Greg's
proposal:
1) Two directory lookups will be required for each recipient of
   an encrypted message.  This added time delay will decrease 
   overall performance.
2) How does this help keep email addresses private?  People will
   mail ACs in messages.  A "spam harvester" could obtain the
   e-mail addresses out of messages in transit or out of the 
   directory.
3) Solves internal/external problem.
4) Favors this approach for gateway address identification.
5) Agrees with Paul Hoffman's comments regarding adding confusion.

An attendee stated that CAs issue certificates and ISPs issue addresses.
He asked whether Greg's proposal assumes that these two entities work
closely together.  Greg answered that an ISP could use an RA to create
certificates.  A system administrator could generate the AC.  He made
the point that the public key certificate generation is much more 
important.

Another attendee stated that he doesn't agree that including e-mail 
addresses in certs is a problem.

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

S/MIME Freeware Library (SFL) - John Pawling

John provided an update briefing regarding the SFL which is a freeware
implementation of RFC 2630 and RFC 2634.  The SFL can be used with the
Crypto++ freeware library to implement RFC 2631.  The SFL provides
functions to support use of RFC 2632 and RFC 2633.  The goal of the SFL
is to provide a reference implementation of RFC 2630 and RFC 2634 to
encourage their acceptance as Internet Standards.  VDA is developing
the SFL.

John briefed that on 14 January 2000, the U.S. Department of Commerce
published revisions to the Export Administration Regulations that 
changed the U.S. Government's encryption export policy. In accordance
with these revised regulations, the unencumbered SFL source code is 
now freely available to everyone at:
http://www.armadillo.huntsville.al.us/software/smime.
Organizations can use the SFL as part of their applications 
without paying any royalties or licensing fees.  There is a public 
license associated the SFL.

The SFL implements the optional RFC 2634 security services such as signed
receipts, security labels, mail list information, signing certificate
attribute and equivalent security labels.  It has been used with the RSA
BSAFE v4.2, Crypto++ v3.1, Fortezza CI and SPYRUS SPEX/ libraries.  VDA
is developing the capability for the SFL to use any security library
that provides a PKCS #11 interface.

John stated that VDA had used the SFL to perform a significant amount
of S/MIME v3 interop testing. VDA tested the majority of features
in RFCs 2630, 2631 and 2634 as well as some of the features in RFCs
2632 and 2633.  

VDA used the SFL to successfully process and produce the majority
of features documented in "Examples of S/MIME Messages".  A summary
of the test results was sent to the S/MIME WG examples mail list 
<[e-mail]>.  Complete test drivers and test data
is available with the SFL.  

S/MIME v3 interoperability testing between the SFL and Microsoft 
successfully tested almost all signedData and envelopedData features
using mandatory, RSA and Fortezza algorithm suites.  For example, 
the SFL (using Crypto++) exchanged E-S D-H-protected envelopedData
with Microsoft. Almost all of the ESS features were tested.  For 
example, successful signed receipt interoperability testing was 
performed between the SFL and Microsoft.  

VDA verified that the SFL can produce and process the majority of 
the features documented in Jim Schaad's S/MIME v3 interoperability
matrix. John sent the matrix to which VDA added the SFL test results
to Jim Schaad for incorporation into the master S/MIME WG matrix.
VDA developed sample objects that illustrate each feature in the
matrix that the SFL supports.  Complete test drivers and test data
are available with the SFL.

SFL interoperability testing is automated through use of test drivers
and configuration files so it can be easily repeated and modified by 
VDA or independently by a third party.  A third party could enhance
the test drivers or incorporate them in an application such as an
S/MIME interoperability testing auto-responder which organizations
could use to test their S/MIME implementations. 

John also provided information regarding the Certificate Management 
Library (CML) that is a freeware implementation of X.509 version 3
certification path verification as specified in the 1997 X.509
Recommendation (except Delta CRLs are not implemented).  
The CML: validates X.509 certification paths and CRLs; provides
local certificate/CRL storage functions; and provides remote
directory retrieval via LDAP.  The CML uses the Certificate Path
Development Library (CPDL) developed by Cygnacom Solutions to
robustly build certification paths including cross certificates.
The CML complies with the majority of the RFC 2459 requirements.
Organizations can use the CML as part of their applications without
paying any royalties or licensing fees (see CML Public License).
All CML source code is provided.  CML is available at:
http://www.armadillo.huntsville.al.us/software.

John also discussed the VDA-enhanced SNACC Abstract Syntax Notation
One (ASN.1) library that implements the Distinguished Encoding
Rules (DER).

John's briefing is stored at ftp://ftp.ietf.org/ietf/smime/ 
and includes additional details regarding the SFL and CML.

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

ETSI Electronic Signature Formats - John Ross

John briefed regarding electronic signature formats for long term 
electronic signatures as part of the ETSI Electronic Signature 
Infrastructure Standardisation.

John briefed that Special Task Force (STF) 155 includes:
Task 1: Policies for Certificate Service Providers (CSP).
	Policy Requirements on CSP issuing Qualified Certificates
Task 2: Electronic Signature Formats
	ETSI ES 201 733 & this Informational RFC
Task 3: Profile for Qualified Certificates
Task 4: Profile for TimeStamping Services

John discussed the "Electronic Signature Formats for long term
electronic signature" I-D, <draft-ietf-smime-esformats-00.txt>.
John briefed that this document is proposed as an Informational RFC. 
It defines the format of an electronic signature that can remain
valid over long periods.  It includes features which can provide 
evidence as to its validity even if the signer later attempts 
to deny (repudiate) the validity of the signature.

John stated that the contents of this Informational RFC will be
technically equivalent to ETSI ES 201 733 V.1.1.1 Copyright (C). 
He noted that the authors do not provide the IETF with any rights
other than to publish as an Internet-Draft.  

John briefed that this document builds on other IETF standards
such as RFC 2630 and RFC 2459.  It will also build on coming 
standards such as the PKIX Timestamping protocol and PKIX AC 
profile.

John discussed the proposal to split the draft document into
two RFCs: one RFC dealing only with ES formats, the other one
dealing only with a Signature Policy format.  In such a case, 
the basis of this split will be, sections 6 and annex C will
be removed from this document and placed in another RFC
dealing with Signature policies.  Also, the signature policy
ASN.1 will be removed the current ASN.1 modules in annex A 
and placed in a new ASN.1 module in the other RFC dealing 
with Signature Policies.  A separate OID for the Signature 
Policy arc would ease separation.

Denis Pinkas made the point that the SigningCertificate signed
attribute provides information about the signer and indicates the
signer's AC that indicates which role the signer used to sign the 
data.

The point was made that the Signature policy Identifier attribute
is used by the signer to indicate the signature policy under which
he is signing.  The Signature policy Identifier attribute will 
contain a hash of the signature policy.  The esformats-00 I-D 
provides further details regarding the definition and use of 
signature policies.

John made the point that the esformats-00 I-D must be equivalent
ETSI ES 201 733 V.1.1.1, so major changes can't be made to the 
esformats-00 I-D.

Sean Turner asked how the ETSI Electronic Signature format relates
to the timestamping work being done in the PKIX WG.  Denis Pinkas
answered that the ETSI Electronic Signature work uses CMS and will
build on the PKIX Timestamping protocol.

Mike Myers asked if the PKIX Data Validation and Certification Server
(DVCS) Protocols would satisfy the ETSI Electronic Signature 
requirements.  Peter Sylvester said that the DVCS protocol could
include the ETSI Electronic Signature information.  Denis stated the
protocols could be used together, but don't have to be.

Sean Turner asked if the S/MIME WG cared about the contents of the 
esformats-00 I-D, since they can't change it anyway.  John Ross
replied that the signature policy portion of the I-D can be changed,
but that the Electronic Signature format can not be changed.  John
welcomed input to the signature policy portion of the I-D.

Russ Housley asked if the signature policy portion of the I-D was
covered under the ETSI copyright.  John Ross said that it was.  He 
further stated that they are working on getting the copyright rules 
relaxed regarding this topic.  ETSI may split the ES 201 733 V.1.1.1 
document into two parts to be consistent with a split in the 
esformats-00 I-D.  A straw poll of the attendees favored splitting 
the esformats-00 I-D.

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

Wrap Up - Russ Housley

Russ stated that the "Use of the CAST-128 Encryption Algorithm in
CMS" I-D was in working group last call.  Jim Schaad stated that
he had provided comments to the document.  Russ stated that 
a new draft of the I-D will be submitted for IETF-wide last call.
 
Russ stated that he would like to issue last call for the 
"Password-based Encryption for S/MIME" I-D.  Jim Schaad stated that
he had provided significant comments to the document.  John Pawling
pointed out that several people had questioned why the I-D defined
yet another key wrapping algorithm.  Russ said that Peter Gutmann
needs to address these comments on the mail list.  Russ pointed
out that the process of transforming a password to a key would
be documented in a separate RFC.

Russ discussed the "Compressed Data Content Type for S/MIME" I-D.  
Peter Gutmann sent a message to the S/MIME WG mail list asking:
"Does anyone have any further thoughts on compression as a CMS 
content type vs a MIME type?"  Russ said that the S/MIME WG
needed to make a decision regarding Peter's question. Paul 
Hoffman stated that compression has been discussed on the
MIME mail list, but it has not been standardized.  He said that
the issue needs to get resolved.  Russ stated that Jeff Schiller
recommended that the S/MIME WG "just do it" because the issue 
needs to be resolved for efficiency purposes.  Russ took a straw
poll and only three people expressed an opinion.

Meeting adjourned.


Received: by ns.secondary.com (8.9.3/8.9.3) id OAA01800 for ietf-smime-bks; Sun, 4 Jun 2000 14:50:35 -0700 (PDT)
Received: from hal9000.vguard.com (vguard.com [192.117.162.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA01793 for <[e-mail]>; Sun, 4 Jun 2000 14:50:30 -0700 (PDT)
Received: by vguard.com with Internet Mail Service (5.5.2650.21) id <L0NAAK25>; Mon, 5 Jun 2000 00:58:55 +0200
Message-ID: <[e-mail]>
From: Raviv Karnieli <[e-mail]>
To: "Russell Housley (E-mail)" <[e-mail]>
Cc: "SMIME WG (E-mail)" <[e-mail]>
Subject: Multiple e-mail addresses
Date: Mon, 5 Jun 2000 00:58:54 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Russ,

I attached the relevant paragraph from the last WG Minutes. I wonder if
farther work was done on these issues, which I find very important for a
workable S/MIMEv3 implementation.

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

Application of Attribute Certificates (AC) in S/MIME - Greg Colla

Greg's briefing addressed the topic of checking the e-mail address
of the signedData signer against the e-mail address in the signer's
certificate.

Greg briefed that there are problems with binding the subject's e-mail
address with the subject's public key in an X.509 public key certificate
such as:
- Multiple e-mail addresses
- Maintenance of e-mail addresses
- Security Proxy (a proxy signs and decrypts on behalf of many users)
- Privacy/Spam

Greg briefed the following requirements:
Address Aliasing: Associate a single entity with multiple e-mail
    addresses, with a single PKC.
Secure Proxying: Associate multiple entities, each with their own
    e-mail address,  with a common PKC.
Address Sharing: Associate multiple entities, each with their own PKC,
    with a single e-mail address.

Greg proposed the following:
- Maintenance of e-mail addresses limits S/MIME usability
- ACs can be used to cryptographically bind e-mail addresses with PK
   certificates
- E-mail ACs provide a flexible solution for maintaining e-mail 
   addresses
- Supplements current infrastructure
- Localized modifications required to S/MIME components to use 
   E-mail ACs
- E-mail ACs can be used to solve other S/MIME limitations

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



Thanks,

Raviv Karnieli - CTO
Vanguard Security Technologies Ltd.
Tel. [phone]       Fax [phone]
www.vguard.com             [e-mail]

This message left my computer secured since I'm using 
MAILguardian Enterprise the first true end to end enterprise e-mail security
solution that is policy based, centrally managed and totally transparent to
the end users.

You can get your own free evaluation copy of MAILguardian 
at http://www.vguard.com/prod.asp




Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA23393 for ietf-smime-bks; Fri, 2 Jun 2000 11:35:07 -0700 (PDT)
Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA23388 for <[e-mail]>; Fri, 2 Jun 2000 11:35:01 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <M16R221X>; Fri, 2 Jun 2000 14:42:24 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: SMIME cert dist draft and X.509
Date: Fri, 2 Jun 2000 14:42:23 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I am not a regular participant on this mailing list, and therefore lack the
history behind this draft. However, as editor of X.509, I'm wondering why
this draft invents new data structures for requirements that, after a very
quick review, I think that X.509 already has standardized structures to
support. From a 509 perspective, I certainly want to understand any
shortcomings that specification has with respect to meeting the needs of the
applications that use public-key certificates.  

Regarding SMimeCapabilities themeselves; was the supportedAlgorithms
attribute from 509 considered? If so, were there specific shortcomings that
it had? Note that it is defined in X.509 as an attribute. Attributes can be
stored in 
directories as part of entries (with or without being digitally signed
and/or encrypted), they can be transferred in application protocols, they
can be included in public-key and attribute certificates. 

Regarding the requirement to tie a set of supported algorithms to a specific
certificate; the construct defined in the Internet draft is semantically an
attribute certificate. Was an X.509 attribute certificate considered and
rejected? If so, what were its deficiencies? Note that there are a number of
ways to identify the holder of an X.509 attribute certificate. One of those
is the hash of a public-key certificate. An attribute certificate that
contained the hash of a public-key certificate and the supportedAlgorithms
attribute seems to provide the functionality you're looking for. If you want
a construct that includes several iterations (i.e.  the set of algorithms
for each public-key certificate), then the X.509 construct
attributeCertificateAttribute seems to provide this because it is a
multivalued attribute that contains values of the attributeCertificate
construct. Again, these can be stored in directories, stored in files,
transferred in application protocols etc.

Regarding PKI path construction; this is an area where a number of different
groups seem to be active. I'm curious why there would be an smime specific
mechanism for this anyway, when if there really is a problem, its probably
not unique 
to smime. PKIX seems like a better place to solve this problem. I'm not sure
I really understand your proposed solution. Are you focused only on
hierarchies or also addressing networked trust models? Why store the path
with the subject's domain when its the relying party's domain where the
information is needed. Why associate it with a user certificate at all,
since the same path (less the user cert) can be reused for any user certs
signed by the same CA? X.509 has a standard attribute called pkiPath that I
think may satisfy the requirement. This attribute contains a sequence of
CA-certificates and its intent is that it stores paths that are frequently
used by the relying parties within the community of a given CA. As such, it
can be used to reduce the number of network connections and directory (or
other protocol) requests to external domains. It is intended to be an
optional facility that may be useful in some environments, but not necessary
in others.

With respect to all of these, my view is that, if directories are being used
as repositories for the information, then ALL public-key certificates issued
to a user be stored in the userCertificate attribute of their directory
entry. This eliminates the need for specialized application-specific tools
on the relying party side to find application specific data. If there are
enhanced mechansims that provide potential efficiencies in an application
specific environment these 
should be optional enhancements and not eliminate the fundamental
interoperability requirement to store information in a common place. I hold
the same view with respect to the pkiPath attribute. If stored in a
directory it should not eliminate the need to store information as defined
in X.509 and profiled by PKIX in the crossCertificatePair and caCertificate
attributes. 

I apologize in advance if, due to my lack of knowledge of the history of
this spec, I'm asking questions that have been previously dealt with and
closed, but felt I should at least ask, in the capacity of X.509 editor.

FYI, if anyone needs to see the X.509 spec, they can obtain it in Word or
pdf format from the following:

ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/

This text has been approved by ITU and is the 2000 edition of X.509,
although many of things I mention were in the 1997 3rd edition text as well.


Sharon  

Sharon Boeyen
Entrust Technologies
[e-mail]


Received: by ns.secondary.com (8.9.3/8.9.3) id HAA14834 for ietf-smime-bks; Fri, 2 Jun 2000 07:46:45 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA14830 for <[e-mail]>; Fri, 2 Jun 2000 07:46:43 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id KAA07253 for <[e-mail]>; Fri, 2 Jun 2000 10:48:01 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 2 Jun 2000 10:52:16 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: Cert Dist Changes
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: dNoxtVldyNpXwrobEyO0rQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> From: "Jim Schaad" <[e-mail]>
> To: "David P. Kemp" <[e-mail]>, <[e-mail]>, 
<[e-mail]>
> Subject: RE: Cert Dist Changes
> Date: Thu, 1 Jun 2000 21:34:34 -0700
> 
> I am a bit loss for words.  Are you saying that data is to appear in one and
> only one location in the directory and not to be duplicated?  If this is not
> the case then I don't see your problem although consistancy can be a problem
> depending on the different tools used to update the directory for different
> purposes.  (A mail program publishing information vs an access control
> program (such as the Win2K directory might not keep/correctly update all
> fields.)
> 
> There is nothing that does not let you put things into the userCertificate
> and caCertificate fields, however many programs only update the
> userCertificate field at present.  The code that I wrote while at Microsoft
> would publish into both the userSMimeCertificate and userCertificate fields
> but ignored the caCertificate field as this exists only on CAs.  This means
> that if a user publishes a certificate in a different directory (possibly
> unaccessable) directory, the client has no way of getting to CA
> certificates, thus for the general case caCertificates is unuseful.


Jim,

That is precisely the situation (CA certificates not being accessible
to all consuming applications) I think we should be trying to avoid.

If you start with a directory environment where caCertificate is not
useful, and you want to allow a particular application (S/MIME) to
operate, you have two possible courses of action:

1) encourage directory administrators to make caCertificate useful, or
2) encourage directory administrators to populate an S/MIME-specific
   attribute to bypass the need for caCertificate.

I believe that option 2 is harmful to the Internet environment.
Once administrators have made the effort to populate a repository with
certificates, the identical repository should be usable by S/MIME, SSL,
IPsec, and other applications.  Developing a stovepipe (single-purpose)
solution is easier in the short run, but will cost us dearly later.

Regards,
Dave




Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id WAA12631 for ietf-smime-bks; Thu, 1 Jun 2000 22:26:18 -0700 (PDT)
Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA12626 for <[e-mail]>; Thu, 1 Jun 2000 22:26:17 -0700 (PDT)
Received: from jimsch1t (ip32.du1.ptl.nwlink.com [209.20.137.32]) by smtp.nwlink.com (8.9.3/8.9.3) with ESMTP id WAA23706; Thu, 1 Jun 2000 22:34:03 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Cert Dist Changes
Date: Thu, 1 Jun 2000 21:34:34 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
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>

I am a bit loss for words.  Are you saying that data is to appear in one and
only one location in the directory and not to be duplicated?  If this is not
the case then I don't see your problem although consistancy can be a problem
depending on the different tools used to update the directory for different
purposes.  (A mail program publishing information vs an access control
program (such as the Win2K directory might not keep/correctly update all
fields.)

There is nothing that does not let you put things into the userCertificate
and caCertificate fields, however many programs only update the
userCertificate field at present.  The code that I wrote while at Microsoft
would publish into both the userSMimeCertificate and userCertificate fields
but ignored the caCertificate field as this exists only on CAs.  This means
that if a user publishes a certificate in a different directory (possibly
unaccessable) directory, the client has no way of getting to CA
certificates, thus for the general case caCertificates is unuseful.

One part of me would be more that happy to deprecate the use of
userCertificate given some of the problems assocated with its use (outlined
in the draft), but I don't expect that to happen any time soon.  What does
it mean if some other application which does not understand or reference the
userSmimeCertificate (having only implemented the PKIX docs) removes a
certificate from userCertificates that is referenced by the
userSmimeCertificate property.  This leads to inconsistancies on the
other-side of the fence if the certificates are not included.  I don't think
that you would ever be able to ensure consistancy unless the directory
itself does so.

jim


-----Original Message-----
From: David P. Kemp [mailto:[e-mail]]
Sent: Thursday, May 18, 2000 7:54 AM
To: [e-mail]; [e-mail]
Subject: Re: Cert Dist Changes


Jim,

If the new draft specifies that the userSmimeCertificate LDAP attribute
contains either user certificates or CA certificates, it is in conflict
with the PKIX directory schema.  *No* certificates should appear in this
attribute, *All* certificates should be populated in the standard PKIX
locations: userCertificate and caCertificate.

Size considerations are a very minor concern to me, although the size
difference between "smimeCapabilities only" and "smimeCapabilities +
full cert path" is significant.  The major concern is the duplication
of data, and the corresponding likelihood that the data will get out of
sync.  If you believe that it is too difficult to fetch certificates
from the directory when formatting a CertDist object for http
retrieval, or alternatively stripping the cert path out when populating
the CertDist object as a directory attribute,  then you certainly must
not be inclined to check CertDist objects which contain certificates
for consistency with the certs already in the userCertificate and
caCertificate attributes of the directory.

SMIME LDAP attribute definitions must be compatible with and
non-duplicative of PKIX LDAP attribute definitions.  Until that is the
case with Certdist, I will continue to oppose its approval as an RFC.

Regards,
Dave



> From: "Jim Schaad" <[e-mail]>
> To: [e-mail]
> Date: Wed, 17 May 2000 21:41:41 +0800
> Subject: Cert Dist Changes
> X-User-Info: 131.107.3.84
>
> Since I have been out of touch and have not be able to respond well to
comments
> on this draft, I will attempt to summerize the comments in this message as
well
> as the action that I have taken about them.  A new draft is on the way to
the
> editors at the same time as this message went out.
>
> 1.  LDAP was not understandable as writen.  I have changed to using the
LDAP
> v2 rather than LDAP v3 descriptions so that they look more like what
people
> understand.  It is perfectly possible that I did not understand what the
v3
> docs were trying to do and so got the v3 schema completely wrong.
>
> 2.  May omit user's certificate if publishing to LDAP.  This is the one
with
> the most traffic.  The arguments that I have found are:
>
> a)  The document should be modified so that the text states that the
certificate
> MUST NOT appear in an LDAP entry.
>
> - I don't like the text MUST NOT.  It is quite possible that when I
prepare
> a CertDist object for publication I don't know where it will appear or it
may
> appear in multiple places.  Putting the MUST NOT text in says that I need
to
> either be able to manipulate the object at publication time or potentially
start
> creating multiple objects.  Note this goes in the opposite direction as
well,
> something move the attribute from LDAP to http get would need to insert
the
> certificate.
>
> b)  The document does not say what do to in the absence of the property.
>
> - I don't believe the document needs to discuss other ways of obtaining
certificates.
>  More specifically the text to deal with this is very LDAP specific and I
don't
> want to tie the document any closer to LDAP than necessary.
>
> c)  Need to look at two attributes to find the certificates.
>
> - Given the relative time involved, I think that most applications are
going
> to pull down multiple attributes at once in any event.  The time involved
in
> pulling down extra bytes vs the time involved in establishing and
re-querying
> to get the correct result seems to me to indicate that all possible
attributes
> should be pulled at once if you even suspect that you might need this.
>From
> my days at Microsoft one of the worse things to do for performance was to
ask
> anything new of the directory or message store.  The cost of doing one
extra
> RPC was just a killer.
>
> d)  Does not work with existing code bases as currently written.
>
> - We are writing standards not documenting existing code.  This implies
that
> we need to do things right and not just document things that are wrong but
already
> in use.
>
>
> RESULT:
>
> I have pulled the MAY text from the document for the following reasons:
> 1.  The reason it was put in was to deal with size issues in the
directory.
>  After looking at this, the savings from not having the end-entity
certificate
> duplicated in a single directory entry, but still having the entire chain
of
> certificates above it duplicated in every end-entity record just seems a
bit
> extreme.  It would be possible for a server which really cared about space
to
> do this operation itself, and do the space savings on chaining
certificates
> as well.
>
> 2.  The difficulty of moving an item from an LDAP to a non-LDAP location
where
> the certificate is inserted or removed as appropriate seems to be a killer
type
> problem.
>
> If the searching abilities are not present, then we need to look at how to
add
> them to the document, but I will need help from some real LDAP people on
how
> to do this.  Please provide me with the necessary set of text and
references
> so that I can understand what you have suggested.
>
> jim
> http://www.nwlink.com
>
>
>
****************************************************************************
*
> This confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
>
****************************************************************************
**