Subject: MIME Parser needed

From: Guangsheng Liu <[email-masked]>
Date: Tue, 27 Jun 2000 16:10:06 -0700

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

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>
Cc: [email-masked]
From: The IESG <[email-masked]>
Subject: Document Action: Use of the IDEA Encryption Algorithm in CMS to Informational
Date: Fri, 30 Jun 2000 06:42:46 -0400
Sender: [email-masked]

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.

Date: Thu, 29 Jun 2000 14:33:11 -0700
To: [email-masked]
From: Guangsheng Liu <[email-masked]>
Subject: what is "Content-Disposition" field?
Sender: [email-masked]

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

From: "Nord, John D Contractor/NCCIM" <[email-masked]>
To: "'Guangsheng Liu'" <[email-masked]>
Cc: [email-masked]
Subject: RE: MIME Parser needed
Date: Wed, 28 Jun 2000 07:37:47 -0500
Sender: [email-masked]

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

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

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

From: "Jim Schaad" <[email-masked]>
Reply-to: [email-masked]
To: [email-masked];[email-masked];;;
Cc: [email-masked]
Date: Tue, 27 Jun 2000 21:44:29 +0800
Subject: Comments on draft-ietf-smime-domsec-05.txt
Sender: [email-masked]

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

Date: Tue, 27 Jun 2000 16:10:06 -0700
To: [email-masked]
From: Guangsheng Liu <[email-masked]>
Subject: MIME Parser needed
Sender: [email-masked]

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

From: William Whyte <[email-masked]>
To: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-smime-idea-05.txt
Date: Tue, 27 Jun 2000 14:11:42 +0100
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-idea-05.txt
Date: Tue, 27 Jun 2000 06:44:15 -0400
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 27 Jun 2000 13:56:19 +0800
From: Wu Xiao Ying <[email-masked]>
Organization: Transparity Ltd.
To: smime <[email-masked]>
Subject: Re: SFL 1.6 on Linux compile problems
Sender: [email-masked]

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

Date: Mon, 26 Jun 2000 09:07:57 -0700
To: Gunnar Kedenburg <[email-masked]>, [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: SFL 1.6 on Linux compile problems
Sender: [email-masked]

This is the wrong mailing list for your question. Please send SFL 
questions to the [email-masked] mailing list.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 26 Jun 2000 18:00:29 +0200
From: Gunnar Kedenburg <[email-masked]>
To: [email-masked]
Subject: SFL 1.6 on Linux compile problems
Sender: [email-masked]

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.

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Blake Ramsdell'" <[email-masked]>
Cc: <[email-masked]>
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
Importance: Normal
Sender: [email-masked]

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: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jim Schaad
> Sent: Friday, June 23, 2000 1:10 PM
> To: Carlisle Adams; 'Blake Ramsdell'
> Cc: [email-masked]
> 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: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Carlisle Adams
> > Sent: Tuesday, June 20, 2000 7:19 AM
> > To: 'Blake Ramsdell'
> > Cc: [email-masked]'
> > 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:[email-masked]]
> > > Sent: 	Monday, June 19, 2000 4:14 PM
> > > To: 	[email-masked]'
> > > 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.
> >
> >
>
>

From: [email-masked]
Date: Fri, 23 Jun 2000 13:05:25 +0100
Subject: Canonicalisation of embedded MIME objects
TO: [email-masked]
Sender: [email-masked]

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.

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Carlisle Adams" <[email-masked]>
cc: [email-masked]
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
Sender: [email-masked]

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:[email-masked]]
Sent: Friday, June 23, 2000 1:10 PM
To: Carlisle Adams; Blake Ramsdell
Cc: [email-masked]
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: [email-masked]
> [mailto:[email-masked]]On Behalf Of Carlisle Adams
> Sent: Tuesday, June 20, 2000 7:19 AM
> To: 'Blake Ramsdell'
> Cc: [email-masked]'
> 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:[email-masked]]
> > Sent: 	Monday, June 19, 2000 4:14 PM
> > To: 	[email-masked]'
> > 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.
>
>

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "Carlisle Adams" <[email-masked]>, "'Blake Ramsdell'" <[email-masked]>
Cc: <[email-masked]>
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
Importance: Normal
Sender: [email-masked]

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: [email-masked]
> [mailto:[email-masked]]On Behalf Of Carlisle Adams
> Sent: Tuesday, June 20, 2000 7:19 AM
> To: 'Blake Ramsdell'
> Cc: [email-masked]'
> 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:[email-masked]]
> > Sent: 	Monday, June 19, 2000 4:14 PM
> > To: 	[email-masked]'
> > 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.
>
>

Date: Fri, 23 Jun 2000 12:35:29 -0700
To: Philip Hallam-Baker <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: New patent claim
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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

From: Philip Hallam-Baker <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Philip Hallam-Baker <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: New patent claim
Date: Fri, 23 Jun 2000 12:16:03 -0700
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
Sent: Friday, June 23, 2000 9:41 AM
To: Philip Hallam-Baker
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
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: (416) 418-1144
------------------------------------------------------------------------
----------

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

                    Philip Hallam-Baker

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

                    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"

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

Date: Fri, 23 Jun 2000 10:52:01 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Last Call: Use of the CAST-128 Encryption Algorithm in CMS toProposed Standard
Sender: [email-masked]

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

>>> [email-masked] 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
[email-masked] or [email-masked] mailing lists by June 27, 2000.

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

From: [email-masked]
Subject: RE: New patent claim
To: Philip Hallam-Baker <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Fri, 23 Jun 2000 09:41:29 -0400
Sender: [email-masked]

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: (416) 418-1144
----------------------------------------------------------------------------------

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

                    Philip Hallam-Baker                                                           
                    <[email-masked]        To:     "'Bruce Greenblatt'"                       
                    m>                         <[email-masked]>, Paul     
                    Sent by:                   Hoffman / IMC <[email-masked]>,                  
                    owner-ietf-smime@ma        [email-masked]                                 
                    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

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: CMS Compressed Data Content Type
Date: Thu, 22 Jun 2000 12:12:27 -0400
Sender: [email-masked]

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
[email-masked]      Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com     Fax. (613) 723-5078

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, June 20, 2000 11:04 AM
To: [email-masked]
Cc: [email-masked]
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 
[email-masked]      Tel. (613) 723-5076 ext. 419 
http://www.chrysalis-its.com     Fax. (613) 723-5078

------_=_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>[email-masked]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel. =
(613) 723-5076 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. (613) 723-5078</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">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: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]</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>[email-masked]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel. =
(613) 723-5076 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. (613) 723-5078</FONT>
</P>

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

From: Philip Hallam-Baker <[email-masked]>
To: "'Bruce Greenblatt'" <[email-masked]>, Paul Hoffman / IMC <[email-masked]>, [email-masked]
Subject: RE: New patent claim
Date: Thu, 22 Jun 2000 07:48:22 -0700
Sender: [email-masked]

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"

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cms-rsaes-oaep-01.txt
Date: Thu, 22 Jun 2000 08:27:40 -0400
Sender: [email-masked]

--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 <[email-masked]> 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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 21 Jun 2000 16:01:22 -0700
To: Paul Hoffman / IMC <[email-masked]>, [email-masked]
From: Bruce Greenblatt <[email-masked]>
Subject: Re: New patent claim
Sender: [email-masked]

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

Date: Wed, 21 Jun 2000 10:15:51 -0700
From: Dennis Glatting <[email-masked]>
To: Paul Hoffman / IMC <[email-masked]>
CC: [email-masked]
Subject: Re: New patent claim
Sender: [email-masked]

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?

Date: Wed, 21 Jun 2000 09:30:33 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: New patent claim
Sender: [email-masked]

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

Date: Tue, 20 Jun 2000 13:25:43 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Agenda Topics
Sender: [email-masked]

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

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: CMS Compressed Data Content Type
Date: Tue, 20 Jun 2000 11:04:06 -0400
Sender: [email-masked]

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
[email-masked]      Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com     Fax. (613) 723-5078

------_=_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>[email-masked]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel. =
(613) 723-5076 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. (613) 723-5078</FONT>
</P>

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

From: Carlisle Adams <[email-masked]>
To: "'Blake Ramsdell'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
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
Sender: [email-masked]

Hi Blake,

Good to hear from you again!

> ----------
> From: 	Blake Ramsdell[SMTP:[email-masked]]
> Sent: 	Monday, June 19, 2000 4:14 PM
> To: 	[email-masked]'
> 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.

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
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
Sender: [email-masked]

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:[email-masked]]
Sent: Friday, June 16, 2000 10:27 AM
Cc: [email-masked]
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
[email-masked] or [email-masked] mailing lists by June 27, 2000.

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

To: IETF-Announce: ;
Cc: [email-masked]
From: The IESG <[email-masked]>
SUBJECT: Last Call: Use of the CAST-128 Encryption Algorithm in CMS to Proposed Standard
Reply-to: [email-masked]
Date: Fri, 16 Jun 2000 13:27:26 -0400
Sender: [email-masked]

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
[email-masked] or [email-masked] mailing lists by June 27, 2000.

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

From: "Owen Carlson" <[email-masked]>
Subject: Your business depends on it #5192
To: [email-masked]
Date: Fri, 16 Jun 2000 00:01:58 -0500
Sender: [email-masked]

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:[email-masked] 
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:[email-masked]?subject=remove
*******************************************************

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: draft-ietf-smime-idea-03
Date: Thu, 15 Jun 2000 14:34:52 -0700
Sender: [email-masked]

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:[email-masked]]
Sent: Monday, June 12, 2000 1:22 AM
To: [email-masked]
Subject: RE: draft-ietf-smime-idea-03

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

jim

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Blake Ramsdell
Sent: Friday, April 14, 2000 4:04 PM
To: [email-masked]'; [email-masked]
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:[email-masked]]
Sent: Friday, April 14, 2000 12:35 AM
To: [email-masked]
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

From: "Alan Shepherd" <[email-masked]>
To: "'Frank W. Nolden'" <[email-masked]>
cc: "ietf-smime" <[email-masked]>
Subject: RE: Does Slime works fine with Windows 2000 PKI
Date: Thu, 15 Jun 2000 10:15:19 +0100
Sender: [email-masked]

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:[email-masked]]
> 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" <[email-masked]>
> To: "Laurent Deffranne" <[email-masked]>
> Cc: "ietf-smime" <[email-masked]>
> 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:[email-masked]]
> > > 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:[email-masked]]
> > > > 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: [email-masked]
> > > > > [mailto:[email-masked]]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.

From: "Tommy Davis" <[email-masked]>
Subject: Disaster Recovery Planning #67A1
To: recove30c
Date: Mon, 12 Jun 2000 22:42:05 -0500
Sender: [email-masked]

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:[email-masked]?subject=remove
///////////////////////////////////////////////////

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: <[email-masked]>
Subject: RE: draft-ietf-smime-idea-03
Date: Mon, 12 Jun 2000 01:22:18 -0700
Importance: Normal
Sender: [email-masked]

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

jim

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Blake Ramsdell
Sent: Friday, April 14, 2000 4:04 PM
To: [email-masked]'; [email-masked]
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:[email-masked]]
Sent: Friday, April 14, 2000 12:35 AM
To: [email-masked]
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

Date: Fri, 09 Jun 2000 08:36:23 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: draft-ietf-smime-idea-04.txt
Sender: [email-masked]

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

From: "Hellrung, Lisa" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: 
Date: Thu, 8 Jun 2000 15:05:54 -0500 
Sender: [email-masked]

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" <[email-masked] <mailto:[email-masked]>>
To: "Hellrung, Lisa" <[email-masked] <mailto:[email-masked]>>
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" <[email-masked] <mailto:[email-masked]>>
> To: <[email-masked] <mailto:[email-masked]>>
> 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.
> >
> >
>

From: "Hellrung, Lisa" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Signed message
Date: Thu, 8 Jun 2000 13:52:32 -0500 
Sender: [email-masked]

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.

From: [email-masked]
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: [email-masked]
Sender: [email-masked]

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

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject: RE: Cert Dist Changes
Date: Wed, 7 Jun 2000 22:46:03 -0700
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of David P. Kemp
> Sent: Friday, June 02, 2000 7:52 AM
> To: [email-masked]
> Subject: RE: Cert Dist Changes
>
>
>
> > From: "Jim Schaad" <[email-masked]>
> > To: "David P. Kemp" <[email-masked]>, <[email-masked]>,
> <[email-masked]>
> > 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

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "Sharon Boeyen" <[email-masked]>, <[email-masked]>
Subject: RE: SMIME cert dist draft and X.509
Date: Wed, 7 Jun 2000 22:46:00 -0700
Importance: Normal
Sender: [email-masked]

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: [email-masked]
[mailto:[email-masked]]On Behalf Of Sharon Boeyen
Sent: Friday, June 02, 2000 11:42 AM
To: [email-masked]'
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
[email-masked]

From: "Archie Reed" <[email-masked]>
Subject: Desktop Artwork For Your Computer !
To: art38d
Date: Mon, 05 Jun 2000 19:12:30 -0500
Sender: [email-masked]

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:[email-masked]?subject=remove
*********************************************************

Date: Mon, 5 Jun 2000 09:19:32 -0400 (EDT)
From: Erynn Schmidt <[email-masked]>
To: [email-masked]
Subject: s/mime v2 vs. v3
Sender: [email-masked]

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

From: Raviv Karnieli <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Final 29 March 2000 S/MIME WG Minutes
Date: Mon, 5 Jun 2000 00:58:49 +0200 
Sender: [email-masked]

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. +972-4-989-1311       Fax +972-4-989-1322
www.vguard.com             [email-masked]

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:[email-masked]]
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 <[email-masked]>

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

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 [email-masked].  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 
<[email-masked]>.  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.

From: Raviv Karnieli <[email-masked]>
To: "Russell Housley (E-mail)" <[email-masked]>
Cc: "SMIME WG (E-mail)" <[email-masked]>
Subject: Multiple e-mail addresses
Date: Mon, 5 Jun 2000 00:58:54 +0200 
Sender: [email-masked]

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. +972-4-989-1311       Fax +972-4-989-1322
www.vguard.com             [email-masked]

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

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: SMIME cert dist draft and X.509
Date: Fri, 2 Jun 2000 14:42:23 -0400 
Sender: [email-masked]

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
[email-masked]

Date: Fri, 2 Jun 2000 10:52:16 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: RE: Cert Dist Changes
To: [email-masked]
Content-MD5: dNoxtVldyNpXwrobEyO0rQ==
Sender: [email-masked]

> From: "Jim Schaad" <[email-masked]>
> To: "David P. Kemp" <[email-masked]>, <[email-masked]>, 
<[email-masked]>
> 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

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "David P. Kemp" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Cert Dist Changes
Date: Thu, 1 Jun 2000 21:34:34 -0700
Importance: Normal
Sender: [email-masked]

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:[email-masked]]
Sent: Thursday, May 18, 2000 7:54 AM
To: [email-masked]; [email-masked]
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" <[email-masked]>
> To: [email-masked]
> 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.
>
****************************************************************************
**