Subject: Comments on draft-ietf-smime-compression-00.txt

From: [email-masked] (Peter Gutmann)
Date: Wed, 29 Mar 2000 15:15:08 (NZST)

Does anyone have any further thoughts on compression as a CMS content type
vs a MIME type?  I think this was more or less beaten to death (and 
beyond :-) the last time it came up, but if anyone has any further thoughts
please post them.

(The password issues are being worked on offline, I'll post an update in a 
 day or two).

Peter.

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 30 Mar 2000 16:26:54 +0930

My personal opinion is that we have given the MIME people a lot of time to
work on this issue.  They have not gotten anyplace that I am aware of so I
think that we need to do it.  If we end up with two ways of doing this then
the S/MIME draft could always say what is to be used for that application.

jim

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Peter Gutmann
Sent: Wednesday, March 29, 2000 3:15 PM
To: [email-masked]
Subject: Comments on draft-ietf-smime-compression-00.txt

Peter.

---

From: Sean Turner <[email-masked]>
Date: Fri, 31 Mar 2000 02:47:40 -0500

I agree with Jim.  Let's do it.

spt

> (The password issues are being worked on offline, I'll post an update in a

Date: Fri, 31 Mar 2000 02:47:40 -0500
From: Sean Turner <[email-masked]>
Organization: IECA, Inc.
To: [email-masked]
CC: Jim Schaad <[email-masked]>, [email-masked]
Subject: Re: Comments on draft-ietf-smime-compression-00.txt
Sender: [email-masked]

I agree with Jim.  Let's do it.

spt

> (The password issues are being worked on offline, I'll post an update in a

Date: Thu, 30 Mar 2000 06:54:16 -0500
To: "Jim Schaad" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Comments on the RSAES-OAEP draft
Cc: "Ietf-Smime" <[email-masked]>
Sender: [email-masked]

Jim:

1. Agree.

2. I cut-and-pasted it from RFC 2630, the place were I made the original 
mistake.

Thanks,
   Russ

At 01:06 PM 03/29/2000 +0930, Jim Schaad wrote:
>1.  Given that the question has been raised on at least one IETF mailing
>list, it might be advisable to state that the public key algorithm for rsa
>in a certificate is the same for v1.5 and v2.0.
>
>2.  You have consistantly gotten the RFC number for the v2.0 draft
>incorrect.  It is 2437 not 2347.
>
>
>jim

From: "Jim Schaad" <[email-masked]>
To: <[email-masked]>, "Ietf-Smime" <[email-masked]>
Subject: RE: Comments on SecLabel draft
Date: Fri, 31 Mar 2000 09:45:47 +0930
Importance: Normal
Sender: [email-masked]

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Jim Schaad
Sent: Wednesday, March 29, 2000 6:48 AM
To: "[email-masked];weston.nicolls"@ey.com;;;;
Subject: Comments on SecLabel draft

SecLabel

1.  Section 1 P2 - Security labels cannot be bound to an encrypted body,
only
to a signed message.

2.  Please give more text explaining the difference between rank and role
based
security.  From the current description they look like the same to me.

3.  The Amoco policy description is not clear.  From the text I assumed that
the confidentiality and integrity were orthogonal axis for make decisions
(thus
leading to 9 items).  Based on the conversation with you this is not true as
the policy is choose one of the axis and then the point on the axis.  The
text
should be clarified as to which is correct.

4. Typo - Section 1.2 last para - "while he outer signature" should be
"while
the".

5.  Section 2.2.1.3 -- I don't think that one should provide a syntax for
the
privacy marks.  However giving a couple of the privacy marks or guidelines
from
the policy on writting them might be useful.  Given that a privacy mark is a
UTF8 string in the syntax, no addtional ASN syntax is really possible.

6.  You say that categories are used informally, however without knowning
how
they would be used or specified I cannot even hope to offer syntax
suggestions.
 Given that they are informal why would they not be marked as privacy
labels.
 If they are categories then I would expect the policy module to do
enforcement
thus being informal would cause some difficulties.

7.  I suggest that you name Clearance in the ASN sections to be XxxxSection.
and the same for the other top level items.
http://www.nwlink.com

From: Philip Hallam-Baker <[email-masked]>
To: "'Jim Schaad'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Comments on draft-ietf-smime-compression-00.txt
Date: Thu, 30 Mar 2000 09:18:58 -0800
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0036_01BF9A42.458A3DF0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I think that the real issue is getting a compression algorithm out
there, any algorithm will do IMHO.

Implementing two sets of switching logic to turn on the compression
is not going to be a killer. In fact I think it is likely to be the
best solution.

Not supporting compression in the base web specs was the biggest 
mistake we made. We could have made 14K modems look like 28.8 modems 
if the early browsers had linked to gnuzip.

The piece that is currently missing is the means of advertising the
capabilities of the client. The biggest problem with messaging
is that the 1% of users with ASCII based clients stop the rest
of the email population using features like MIME, HTML, S/MIME
etc.

I can see that we might have problems if we were using a framework
like RDF to address this issue and the mechanism did not account
for the fact that clients might be able to do compressin in S/MIME 
but not in MIME (or vice versa).

Perhaps the real solution to this problem is to approach it
from another direction entirely. Rather than the RDF piecemeal
description of supported features maybe we should define client
profiles specifying feature sets that make sense. Then we could
distribute client capability info with a single certificate 
attribute.

		Phill

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]]
Sent: Thursday, March 30, 2000 1:57 AM
To: [email-masked]; [email-masked]
Subject: RE: Comments on draft-ietf-smime-compression-00.txt

My personal opinion is that we have given the MIME people a lot of time
to
work on this issue.  They have not gotten anyplace that I am aware of so
I
think that we need to do it.  If we end up with two ways of doing this
then
the S/MIME draft could always say what is to be used for that
application.

jim

-----Original Message-----

Does anyone have any further thoughts on compression as a CMS content
type
vs a MIME type?  I think this was more or less beaten to death (and
beyond :-) the last time it came up, but if anyone has any further
thoughts
please post them.

(The password issues are being worked on offline, I'll post an update in
a
 day or two).

Peter.

------=_NextPart_000_0036_01BF9A42.458A3DF0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0036_01BF9A42.458A3DF0--

From: "Jim Schaad" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments on draft-ietf-smime-compression-00.txt
Date: Thu, 30 Mar 2000 16:26:54 +0930
Importance: Normal
Sender: [email-masked]

jim

-----Original Message-----

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re:  Compressed Data Content Type for S/MIME
Reply-To: [email-masked]
Date: Thu, 30 Mar 2000 03:56:15 (NZST)
Sender: [email-masked]

Maxim Masiutin <[email-masked]> writes:

>There is "PasswordRecipientInfo" defined in "Appendix A: ASN.1 Module" of 
>ietf-smime-compression-00.txt
>
>There are no references to PasswordRecipientInfo. How should we handle it?

By replacing it with "CompressedDataContent" :-).  I copied the OID across
from another draft and the text came with it.  Also it's listed as (n+1) 
(equivalent to the '?' or 'TBA' from other CMS drafts) where n currently 
appears to be 6 (id-mod-ets-eSignature-97), does anyone have any objections 
to id-mod-compression being 7?  In addition it looks like the listed value 
for id-ct-compressedData has been overtaken by newer drafts, since the 
highest one listed is id-ct-contentInfo(6) are there any problems with 
id-ct-compressedData being 7 as well?

(Before anyone points this out, I need to update the [CMS] reference as well,
 I know... draft-00 goes back awhile).

Peter.

From: "Jim Schaad" <[email-masked]>
Reply-to: [email-masked]
To: [email-masked];[email-masked];;;
Date: Wed, 29 Mar 2000 05:17:38 +0800
Subject: Comments on SecLabel draft
Sender: [email-masked]

SecLabel

1.  Section 1 P2 - Security labels cannot be bound to an encrypted body, only
to a signed message.

2.  Please give more text explaining the difference between rank and role based
security.  From the current description they look like the same to me.

3.  The Amoco policy description is not clear.  From the text I assumed that
the confidentiality and integrity were orthogonal axis for make decisions (thus
leading to 9 items).  Based on the conversation with you this is not true as
the policy is choose one of the axis and then the point on the axis.  The text
should be clarified as to which is correct.

4. Typo - Section 1.2 last para - "while he outer signature" should be "while
the".

5.  Section 2.2.1.3 -- I don't think that one should provide a syntax for the
privacy marks.  However giving a couple of the privacy marks or guidelines from
the policy on writting them might be useful.  Given that a privacy mark is a
UTF8 string in the syntax, no addtional ASN syntax is really possible.

6.  You say that categories are used informally, however without knowning how
they would be used or specified I cannot even hope to offer syntax suggestions.
 Given that they are informal why would they not be marked as privacy labels.
 If they are categories then I would expect the policy module to do enforcement
thus being informal would cause some difficulties.

7.  I suggest that you name Clearance in the ASN sections to be XxxxSection.
and the same for the other top level items.
http://www.nwlink.com

Date: Wed, 29 Mar 2000 15:21:25 +0300
From: Maxim Masiutin <[email-masked]>
Organization: RIT Research Labs
To: Peter Gutmann <[email-masked]>
Subject: Compressed Data Content Type for S/MIME
Sender: [email-masked]

Hello Peter!

  There is "PasswordRecipientInfo" defined in "Appendix A: ASN.1
  Module" of ietf-smime-compression-00.txt

  There are no references to PasswordRecipientInfo. How should we
  handle it?

-- 
Max Masyutin,
Software Engineer
RIT Research Labs  http://www.ritlabs.com/

From: "Jim Schaad" <[email-masked]>
To: "Ietf-Smime" <[email-masked]>
Cc: "Russ Housley" <[email-masked]>
Subject: Comments on the RSAES-OAEP draft
Date: Wed, 29 Mar 2000 13:06:15 +0930
Importance: Normal
Sender: [email-masked]

1.  Given that the question has been raised on at least one IETF mailing
list, it might be advisable to state that the public key algorithm for rsa
in a certificate is the same for v1.5 and v2.0.

2.  You have consistantly gotten the RFC number for the v2.0 draft
incorrect.  It is 2437 not 2347.

jim

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Comments on draft-ietf-smime-compression-00.txt
Reply-To: [email-masked]
Date: Wed, 29 Mar 2000 15:15:08 (NZST)
Sender: [email-masked]

Peter.

From: =?UTF-8?B?UGF3bGluZywgSm9obg==?= <[email-masked]>
To: =?UTF-8?B?J0ppbSBTY2hhYWQgJw==?= <[email-masked]>, =?UTF-8?B?J0NhbWVyb24gU3RpbGxpb24gJw==?= <[email-masked]>, =?UTF-8?B?J2lldGYtc21pbWVAaW1jLm9yZyAn?= <[email-masked]>
Cc: =?UTF-8?B?J0JyeWFuIFN0YWF0cyAn?= <[email-masked]>
Subject: =?UTF-8?B?UkU6IEVTUyA6IFNlY3VyZSBSZWNlaXB0IGVuY29kaW5nIHdpdGhp?= =?UTF-8?B?biBFbmNhcHN1bGF0ZWRDb250ZW50SW5mbw==?=
Date: Mon, 27 Mar 2000 22:08:34 -0500
Sender: [email-masked]

Jim,

I agree with all of your statements except for bullet #3.  You stated that
the OCTET wrapping can be omitted if an ESS receipt content-type is
encapsulated within a PKCS#7 signedData.  This would cause severe
interoperability problems with an RFC 2630/RFC 2634 (a.k.a. CMS/ESS)
implementation such as the S/MIME Freeware Library.    

RFC 2630 (CMS) defines EncapsulatedContentInfo as follows:
 EncapsulatedContentInfo ::= SEQUENCE {
      eContentType ContentType,
      eContent [0] EXPLICIT OCTET STRING OPTIONAL }

If the eContent field is present, then the OCTET STRING tag and length
octets must be present in the encoding of the signedData.
 
RFC 2634 (ESS), Section 2.4, bullet 9 states: "The ASN.1 DER encoded
Receipt content MUST be directly encoded within the signedData
encapContentInfo eContent OCTET STRING defined in [CMS]."

Notice the text "defined in [CMS]".  A valid encoding of an ESS signed
receipt MUST contain the signedData encapContentInfo eContent OCTET STRING
tag and length octets.  If the eContent OCTET STRING tag and length octets
are omitted (as you suggest in your message), then a CMS/ESS implementation
cannot decode the message.

There is no text in ESS that addresses the inclusion of a receipt content in
a PKCS #7 signedData.  If there was such text, it would need to state that
the ASN.1 DER encoded Receipt content MUST be directly encoded within an
OCTET STRING within the PKCS #7 signedData contentInfo content
defined in PKCS #7.  This is the only way (without changing the CMS
encapContentInfo eContent syntax) that signed receipt interoperability can
be achieved between CMS/ESS and PKCS #7/ESS implementations.  

If you believe that there will be PKCS #7/ESS implementations that are
sending signed receipts, then the aforementioned text needs to be included
in RFC 2634.

Thank you for your feedback,
-John Pawling

Date: Mon, 27 Mar 2000 05:32:42 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: RE: LAST CALL:draft-ietf-smime-password-02.txt
Cc: [email-masked]
Sender: [email-masked]

Peter:

One of the first decisions that the S/MIME working group made was to use 
1988 ASN.1.  This decision was made for several reasons, including the 
availability of compilers.  So, if you want this to move forward as part of 
the S/MIME Standards Track document series, then you will have to reverse 
port the ASN.1.

Russ

From: "Jim Schaad" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: LAST CALL:draft-ietf-smime-password-02.txt
Date: Mon, 27 Mar 2000 17:03:35 +0930
Importance: Normal
Sender: [email-masked]

Here are the set of last call comments that I have for this draft.

1.  You still have a reference to PKCS #5 v2 in the document. (PKCS#5 v2 is
not an information or other RFC.)  If you want this document to be on
standards track rather than informational then this issue needs to be
resolved.

2.  Section 2.1.  The S/MIME working group is using 88 ASN syntax.  The
syntax in this section is not.  Please correct.

<previous response from peter>
PKCS #5 uses current ASN.1 syntax and not the 1988 version, the ASN.1 used
is taken straight from the standard.

3.  Section 2.1  Why is there ASN here that does not actually provide any
useful information.  What are the parameters.  What is the OID associated
with this set of parameters.  This is an issue for both the fact that PKCS#5
is not an RFC and the ASN.1 is not 1988.

<previous response from peter>
It's copied from PKCS #5 for completeness, I didn't want to include the
whole thing verbatim but did want to include enough information that readers
wouldn't have to keep flipping back and forth between the two.

4.  Section 2.3.1 - I will raise the issue of the fact that the key wrap
algorithm is not the same as CMS even though the CMS version is a MUST
implement.  At a minimum you should make the CMS version the MUST and the
version you have in your document an optional version to have.

5.  Based on a past email with Carlisle Adams, I think that changing title
to "Password-based Encryption for CMS" is a reasonable thing to do.

6.  Why does a version with keyDerivation optional exist in this draft?  It
appears to me that this is exactly the same thing as is done by
kekRecipientInfo (i.e. an existing KEK key is used to wrap a CEK key).  I
would not be in favor of having two different methods for doing this.

7.  I don't understand why onlyi the first 3 bytes of the CEK are used for
the checksum.  What is the problem with using the first 3 bytes of a SHA1
hash.  I don't think the performance difference is going to be significant.

8.  The test vectors should be modified to use one of the standard CMS
algorithms if they are going to be present in the draft.  Blowfish is not an
algorithm that one should expect most CMS developers to have implemented.
RC2 and 3DES are.

jim

From: "Jim Schaad" <[email-masked]>
To: <[email-masked]>
Cc: "Carlisle Adams" <[email-masked]>
Subject: RE: LAST CALL: draft-ietf-smime-cast-128-01.txt
Date: Mon, 27 Mar 2000 16:31:06 +0930
Importance: Normal
Sender: [email-masked]

I have the following comments on the draft at this stage.  I am sorry for
being late, but I have been on holidays.

1.  In section 3 paragraph 1 -- The size needs to be required for an
SMimeCapablity and cannot be MAY.  We do binary comparisions to see if the
algorithms are the same so there can be no MAY fields.

2.  In section 3 --  Again I ask that you include the actual list of bytes
that are to be used for the SMimeCaps fields.  For an example of what I am
looking for you can look at section 7 of CMSKEA.  Due to the fact that a
binary comparision is being done, it is best to allow for no errors in the
encoding of this field.

Jim Schaad

From: "Jim Schaad" <[email-masked]>
To: "Cameron Stillion" <[email-masked]>, <[email-masked]>
Cc: "Bryan Staats" <[email-masked]>
Subject: RE: ESS : Secure Receipt encoding within EncapsulatedContentInfo
Date: Mon, 27 Mar 2000 09:55:42 +0930
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0004_01BF97D2.9CF82E20
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Just to be a little more clare abouit this.  My response would be as
follows:

1.  It is stated that the reciept must be DER encoded.
2.  The directly statement is made with respect to the lack of a MIME =
layer
being inserted between the receipt content and the surrounding =
SignedData
ASN construct (i.e. the MIME layer is omitted unlike what is done in
wrapping a signed message in an encrypted message).
3.  The OCTET wrapping or lack of is addressed by either PKCS#7 or CMS
drafts.  It is present for CMS and omitted for PKCS#7.

jim

-----Original Message-----
From: [email-masked] =
[mailto:[email-masked]]On
Behalf Of Cameron Stillion
Sent: Friday, March 10, 2000 11:45 AM
To: [email-masked]'
Cc: [email-masked]'; Bryan Staats
Subject: ESS : Secure Receipt encoding within EncapsulatedContentInfo

... and now for something completely different:
=20
According to the ESS RFC on page 16, step 9:
=20
9.  The ASN.1 DER encoded Receipt content MUST be directly encoded =
within
the signedData encapContentInfo eContent OCTET STRING defined in [CMS].

Should eContent be a DER-encoding of the receipt?
    or
Should eContent be a DER-encoding of an OCTET STRING containing the
DER-encoding of the receipt?
=20
The word "directly" seems to indicate that the former is the correct =
one.
Just tell me I'm not crazy.
=20
Cameron Stillion

------=_NextPart_000_0004_01BF97D2.9CF82E20
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="winmail.dat"

------=_NextPart_000_0004_01BF97D2.9CF82E20--

From: "Owen" <[email-masked]>
Subject: Get Ready For Some Mail That You Like
To: [email-masked]
Date: Sun, 26 Mar 2000 14:37:15 -0500
Sender: [email-masked]

Hi,

Perhaps this might be of interest to you.

HERE IS YOUR REQUESTED INFORMATION!:
 
Fellow entrepreneur:

Don't knock it until you at least read this.  

For the first time ever, I have received a piece of
email that actually delivered more than just empty promises!
 
5LIST!  = $$$$$ IN THE BANK!

Perhaps this might be of interest to you?

GET PAID $5 PER SIGNUP TO BUILD YOUR OWN MAIL LIST!
.......why do it for free??
(Example: you get 10
   they get 10ea.=100
  they get 10 ea.=1000
WOW!~Each sending $5 to you=WOW!)

If you need to make a few thousand dollars REALLY FAST, then please,
take a moment to read this simple program I am sharing with you.

You DO NOT have to send $5 to five people, buy their reports, or
recipes, or anything like that. Nor will you have to invest more
money later to get things going.
 
THIS IS THE FASTEST, EASIEST PROGRAM YOU WILL EVER DO.  
 
Complete it in one hour, and you will never forget the day you first
received it.

The following is a plan to benefit you and your future. $$$$$ BE
PREPARED TO GET EXCITED...YOU WON'T BE   DISAPPOINTED!!!

Read the following and you will agree this is a very exciting 
opportunity. Only invest a little bit of time, and your reward could
mean thousands of dollars! Good luck!
 
*********************************************************************
************ 
&ldquo;IT'S OUTRAGEOUS!!!  With two hours of work I have made over US
$11,000 In the last three weeks&hellip;..and my investment was just 
$5!!!  I LOVE IT!
Thank you 11,000 x's!&rdquo; -Julie M. St. Louis
*********************************************************************
*********** ARE YOU IN
NEED OF MONEY RIGHT NOW?  HOW DOES $10,000 IN TWO WEEKS SOUND?  Don't
laugh!  
Try this, for a change, while you wait for the others to start
working. 
One hour of work to get started and no mailing lists!
 
*********************************************************************
******
Esquire Marketing Newsletter Gift Club. This service is 100% 
legal (Refer to US Postal and Lottery Laws, Title18, Section 1302 and
1341, or Title 18, Section 3005 in the US code, also in the code of
federal regulations, Volume 16,  Sections 255 and 436, which state "a
product or service must be exchanged for
money received")
*********************************************************************
**********
Here's How It Works:  Unlike many other programs, this three level
program is more realistic  and much, much faster. Because it is so
easy, the response rate for this program is VERY HIGH AND VERY FAST,
and you will see results in two weeks or less!
 
Just in time for next month's bills! You only mail out 20 copies (not
200 or more as in other programs). You should also send them to
people who send you their programs, because they know these programs
work and they are already believers in the
system!

Besides, this program is MUCH, MUCH FASTER and has a HIGHER  RESPONSE
RATE! Even if you are already in a program, stay with it, but do
yourself a favor and DO THIS ONE as well.  

START RIGHT NOW!  It's simple and takes a very small investment.
It will pay off long before other letters even begin to trickle in!

$$$$$

Just give ONE person a $5 gift.  That's all!

$$$$$

Follow the simple instructions and in two weeks you will have US$10,0
00 in your bank account!  Because of the LOW INVESTMENT, SPEED, and
HIGH PROFIT POTENTIAL, this program has a VERY HIGH RESPONSE RATE!
Just one
(1) US $5 bill.  That's your investment!!!

*********************************************************************
**********
Follow These Simple Instructions:

1) On a blank sheet of paper write "Please add me to your mailing
list." Write your name and address clearly and  include your email
address for future mailings and courtesy follow ups.  
 
Fold it around a US $5 and send it to the FIRST name on the list (#1)
.  Only the first person on the list  gets your name and a
five dollar gift.

2) Retype only the list,  removing the FIRST (#1)  NAME FROM THE LIST
.  Move the other two names UP and ADD YOUR NAME   to the list in the
THIRD (#3) position.

3) Send out 20 copies of this letter.  NOTE: by sending this letter
via    EMAIL, The response time is much faster, and you
save the expenses of envelopes,stamps, and copying services

Consider this; MILLIONS of people "surf the Internet"everyday, all
day, all over the world! Fifty thousand new people get on the
Internet every month!  An excellent source of names are the people
who send you other programs and the names listed onthe letter they
send you.  
Your contact source is UNLIMITED!  It boggles my mind to think of all
the possibilities! 

Mail, or should I say Email, your letter TODAY!  It's so easy. One
hour of your time.  THAT'S IT!

To send your newsletter by Email:
1) Go to "edit" and "select all"
2) Go to "edit" and "copy"
3) Start (compose) a new Email message
4) Address your Email and Subject blocks
5) Go to "edit" and "paste".
After you have pasted this article to your new Email, 
delete the old header and footer (Subject, Date, To, From, Etc.)  
Now you can edit the names and addresses with ease. 
I recommend deleting the top name, adding your name and address to
the bottom of the list, then simply changing the numbers.

THERE'S NOTHING MORE TO DO.  
When your name reaches the first position in a few days, it will be
your turn to collect your gifts.  The gifts will be sent to you by
1,500 to 2,000 people like yourself, who are willing to invest US $5
and one hour to receive US $10,000 in cash. That's all!  

There will be a total of US$10,000 in US$5 bills in your mailbox in
two weeks. US$10,000 for one hour&rsquo;s work!  I think it's WORTH
IT, don't you?
 
GO AHEAD...TRY IT.  IT'S US$5!... EVEN IF YOU MAKE JUST 3 OR 4
THOUSAND,  WOULDN'T THAT BE
NICE?  IF YOU TRY IT, IT WILL PAY!

*********************************************************************
*********** 
TRUE STORY
Cindy Allen writes:  
&ldquo;I ran this gift summation four times last year. The first time
I received over $7,000 in cash in less than two weeks and
over $10,000 in cash in the next three times I ran it.  I can't begin
to tell you how great it feels Not to have to worry about
money anymore!  I thank God for the day I received this letter! It
has truly changed my life!  
 
Don't be afraid to make gifts to strangers, they'll come back to you
in ten-fold.  
 
So, let's keep it going and help each other out in these "tough and
uncertain times."

*********************************************************************
*********** 
CAN I DO IT AGAIN? OF COURSE YOU CAN
this plan is structured for everyone to send only 20 letters each. 
However, you are certainly not limited to 20. Mail out as many as you
can.  Every 20 letters you send has a return of $10,000
or more.   If you can mail forty, sixty, eighty, or whatever, 
 
GO FOR IT!  THE MORE YOU PUT INTO IT, 
THE MORE YOU GET OUT OF IT

Each time you run this program, just follow steps 1 thru 3 and
everyone on your gift list benefits! Simple enough? You bet it is!
Besides, there are no mailing lists to buy,(and wait for), and trips
to the printer or copier, and you can do it again and again,
with your regular groups or gifters, or start up a new group.
 
Why not?  It beats working!  

Each time you receive an MLM offer, Respond with this letter!  
Your name will climb to the number one position at dizzying rates
Follow the simple instructions, and above all, PLEASE PLAY FAIR.
That's the key to this program&rsquo;s success. Your name must run
the full gamut on the list to produce the end results.
Sneaking your name higher up on the list WILL NOT produce the results
as you think, 
and it only cheats the other people who have worked hard and have
earned the right to be there.  
 
So please, 
play by the rules and the $$$ will come to you!

*********************************************************************
***********
MAIL YOUR LETTERS OUT TODAY!

 $$$  
 Together we will prosper!  
 $$$ GOOD LUCK!!!

*********************************************************************
************
1.   Bonnie Mallalieu                                                
               
      MC Box 5179
      Clinton, MS 39058
 
2.   FWM Marketing
      1602 N Maryland Ave
       Plant City, Fl 33556

3.   Paul D. Gram
      16277 NW 20th St
      Pembroke Pines, Fl. 33028

*********************************************************************
********** 
Wishing you the best in all you do! You probably don't believe this
will work, but if you don't try it, you will never know. That's the
way I felt.  
Try it.  You won't be sorry. 
Paul Gram

For support and to Maximize your success Email me with "5list"in
subject heading along with a copy of your re-done list
*********************************************************************
************
IMPORTANT: This is a one and only email, if you do not join, if you
are not interested or even if you are interested, you will
not get any more email regarding this from me. It is up to you now.
*********************************************************************
*********** 
WISHING YOU THE BEST LIFE HAS TO OFFER!

*********************************************************************
***************
Please Remove at:
mailto:[email-masked]?subject=remove
*********************************************************************
***************

Date: Thu, 23 Mar 2000 11:43:06 -0800
From: Guang Yee <[email-masked]>
To: "Pawling, John" <[email-masked]>
CC: "'SMIME WG'" <[email-masked]>
Subject: Re: v1.5 SFL Freely Available to All!!
Sender: [email-masked]

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

John,

Is SFL v1.5 currently available on HP? If not, when will SFL v1.5 be ported to
HP?

Thanks,

Guang

"Pawling, John" wrote:

> All,
>
> J.G. Van Dyke and Associates (VDA), a Wang Government Services Company, has
> delivered Version 1.5 of the S/MIME Freeware Library (SFL) source code and
> Application Programming Interface (API).  The SFL source code files are
> freely available to everyone from the Fortezza Developer's S/MIME Page
> <http://www.armadillo.huntsville.al.us/software/smime> (with no password
> control).  On 14 January 2000, the U.S. Department of Commerce, Bureau of
> Export Administration published a new regulation implementing an update to
> the U.S. Government's encryption export policy
> <http://www.bxa.doc.gov/Encryption/Default.htm>.  In accordance with the
> revisions to the Export Administration Regulations (EAR) of 14 Jan 2000,
> the downloading of the SFL source code is no longer password controlled.
>
> The SFL implements the IETF S/MIME v3 RFC 2630 Cryptographic Message
> Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS) specifications.
> It also implements portions of the RFC 2633 Message Specification and
> RFC 2632 Certificate Handling document.  When used in conjunction with
> the Crypto++ freeware library, the SFL implements the RFC 2631
> Diffie-Hellman (D-H) Key Agreement Method specification.  It has been
> successfully tested using the MS Windows NT/95/98 and Solaris 2.7 operating
> systems.  Further enhancements, ports and testing of the SFL are still in
> process.  Further releases of the SFL will be provided as significant
> capabilities are added.
>
> The SFL has been successfully used to sign, verify, encrypt and decrypt
> CMS/ESS
> objects using: S/MIME v3 mandatory-to-implement algorithms (DSA, E-S D-H,
> 3DES)
> provided by the Crypto++ 3.1 library; RSA suite of algorithms provided by
> the
> RSA BSAFE v4.2 and Crypto++ 3.1 libraries; and Fortezza suite of algorithms
> provided by the Fortezza Crypto Card.  The SFL uses the VDA-enhanced SNACC
> v1.3
> ASN.1 Library to encode/decode objects. The v1.5 SFL release includes: SFL
> High-
> level library; Free (a.k.a. Crypto++) Crypto Token Interface Library (CTIL);
>
> BSAFE CTIL; Fortezza CTIL; SPEX/ CTIL; PKCS #11 CTIL (still being tested);
> VDA-
> enhanced GNU SNACC v1.3 rev 0.07 ASN.1 Compiler and Library; test utilities;
>
> test drivers and test data.  All CTILs were tested as Dynamically Linked
> Libraries (DLL) using MS Windows.  The Fortezza, BSAFE and Crypto++ CTILs
> were
> tested with the respective security libraries as shared objects using
> Solaris 2.7.
>
> The SFL has been successfully used to exchange signedData and envelopedData
> messages with the Microsoft (MS) Internet Explorer Outlook Express v4.01 and
>
> Netscape Communicator 4.X S/MIME v2 products.  Signed messages have been
> exchanged with the RSA S/MAIL, WorldTalk and Entrust S/MIME v2 products.
>
> The SFL has also been used to perform S/MIME v3 interoperability testing
> with
> Microsoft that exercised the majority of the features specified by RFCs
> 2630,
> 2631 and 2634.  This testing included the RSA, mandatory S/MIME V3 and
> Fortezza
> suites of algorithms.  We have also performed limited S/MIME v3 testing with
>
> Baltimore and Entrust.  We are also participating in the IETF S/MIME WG
> interoperability testing documented in the "Examples of S/MIME Messages"
> document.  We have used the SFL to successfully process all of the correct
> signedData and envelopedData messages included in the document.  We are
> continuing to set up test config files to use the SFL to test the other
> cases
> included in the document such as signed receipts.  We also plan to provide
> sample messages for inclusion in the document.
>
> The following enhancements are included in the v1.5 SFL release (compared
> with
> the v1.4 release):
>
> 1) SNACC: Fixed ASN.1 INTEGER bug in which one-byte values were improperly
> processed.
>
> 2) Fixed many memory leaks;
>
> 3) Full CounterSignature test suite (autohiAllSFLd.cfg);
>
> 4) CertificateBuilder utility generates private/public key pairs and
> certificates (there is a "README.txt" file in the root directory regarding
> this
> utility).
>
> 5) PKCS #11 CTIL project (SFL integrators need to separately obtain a PKCS
> #11
> crypto library, but this project provides a good template for PKCS #11).  We
>
> are still testing the PKCS #11 CTIL.
>
> 6) Developed new test code and configuration files to implement test cases;
> and
>
> 7) Performed regression testing to ensure that aforementioned enhancements
> did
> not break existing SFL functionality.
>
> We are still in the process of enhancing and testing the SFL.  Future
> releases
> will include: completion of PKCS #11 CTIL testing; SPEX/ CTIL
> encrypt/decrypt/ESDH capabilities; finish CertificateBuilder command line
> utility; modify PKCS #12 code in test utilities to provide interoperable key
>
> storage; add "Certificate Management Messages over CMS" ASN.1 encode/decode
> functions; add enhanced test routines; bug fixes; support for other crypto
> APIs
> (possible); and support for other operating systems.
>
> The SFL is developed to maximize portability to 32-bit operating
> systems.  In addition to testing on MS Windows and Solaris 2.7, we plan to
> port
> the SFL to the following operating systems: Linux, HP/UX 11, IBM AIX 3.2
> (possibly), SCO 5.0 (possibly) and Macintosh (possibly).
>
> The following SFL files are available from the Fortezza Developer's S/MIME
> Page:
>
> 1) SFL Documents: Fact Sheet, Software Design Description, API, CTIL API,
> Software Test Description, Implementers Guide, Overview Briefing and Public
> License.
>
> 2) snacc1_5VDA.zip: Zip file containing SNACC v1.3 rev 0.07 ASN.1 Compiler
> and
> Library source code compilable for Unix and MS Windows NT/95/98 that has
> been
> enhanced by VDA to implement the Distinguished Encoding Rules.  Project
> files
> and makefiles are included.  This file includes a sample test project
> demonstrating the use of the SNACC classes.
>
> 3) smimeR15.zip:  Zip file containing all SFL source code including:
> SFL Hi-Level source code; VDA-enhanced SNACC-generated ASN.1 source
> code; project files.  This file also contains test driver source code,
> sample CMS/ESS test data and test X.509 Certificates.  This file also
> includes test utilities to create X.509 Certificates that each include
> a D-H, DSA or RSA public key.  SNACC release and debug libraries
> are compiled for MS Windows NT/95/98. MS Windows NT/95/98
> project files and Unix makefiles are included for the SNACC code and
> Crypto++.
>
> 4) smR15CTI.zip:  Source code for the following CTILs: Test (no crypto),
> Crypto++, BSAFE, Fortezza, SPEX/ and PKCS #11.  The Win95/98/NT projects are
>
> also included.  (NOTE: The Free (a.k.a. Crypto++) CTIL includes
> VDA-developed
> source code to use the RSA public key algorithm implemented within the
> external
> Crypto++ library.  As with all of the external crypto token libraries, the
> Crypto++ library is not distributed as part of the SFL source code.
> To use the Crypto++ library with the SFL, the application developer must
> independently obtain the Crypto++ library from the Crypto++ Web Page
> <http://www.eskimo.com/~weidai/cryptlib.html> and then compile it with
> the VDA-developed Crypto++ CTIL source code.  The RSA public key
> algorithm is covered by U.S. Patent 4,405,829 "Cryptographic Communication
> System and Method".  Within the U.S., users of the RSA public key algorithm
> provided by the external Crypto++ library must obtain a license from RSA
> granting them permission to use the RSA algorithm.)
>
> 5) csmime.mdl contains SFL Class diagrams created using Microsoft
> Visual Modeler (comes with MS Visual Studio 6.0, Enterprise Tools).
> The file can also be viewed using Rational Rose C++ Demo 4.0
> 45 day evaluation copy which can be obtained from
> <http://www.rational.com/uml/resources/practice_uml/index.jtmpl>.
> Not all classes are documented in the MDL file at this time.
>
> All source code for the SFL is being provided at no cost and with no
> financial limitations regarding its use and distribution.
> Organizations can use the SFL without paying any royalties or
> licensing fees.  VDA is developing the SFL under contract to the U.S.
> Government.  The U.S. Government is furnishing the SFL source code at no
> cost to the vendor subject to the conditions of the "SFL Public
> License" available from the VDA SFL Page and Fortezza Developer's
> S/MIME Page.
>
> The SFL is composed of a high-level library that performs generic CMS
> and ESS processing independent of the crypto algorithms used to
> protect a specific object.  The SFL high-level library makes calls to
> an algorithm-independent CTIL API.  The underlying, external crypto
> token libraries are not distributed as part of the SFL
> source code. The application developer must independently obtain these
> libraries and then link them with the SFL.  For example, the SFL uses
> the freeware Crypto++ library to obtain 3DES, D-H and DSA.  To use
> the SFL with Crypto++ the vendor must download the Crypto++ freeware
> library from the Crypto++ Web Page and then compile it with the
> VDA-developed Crypto++ CTIL source code.
>
> The Internet Mail Consortium (IMC) has established an SFL web page
> <http://www.imc.org/imc-sfl>.  The IMC has also established an SFL
> mail list which is used to: distribute information regarding SFL
> releases; discuss SFL-related issues; and provide a means for SFL
> users to provide feedback, comments, bug reports, etc.  Subscription
> information for the imc-sfl mailing list is at the IMC web site
> listed above.
>
> The SFL documents and VDA-enhanced SNACC source code are also
> available from the VDA SFL Web Page
> <http://www.jgvandyke.com/services/infosec/sfl.htm>.
>
> All comments regarding the SFL source code and documents are welcome.
> We recommend that comments should be sent to the imc-sfl mail list.
> We will respond to all messages on that list.
>
> ============================================
> John Pawling, Director - Systems Engineering
> J.G. Van Dyke & Associates, Inc;
> a Wang Government Services Company
> [email-masked]
> ============================================

--------------8B518FEC5C6CAE5D1E8289D6
Content-Type: text/x-vcard; charset=us-ascii;
 name="gyee.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Guang Yee
Content-Disposition: attachment;
 filename="gyee.vcf"

begin:vcard 
n:Yee;Guang
tel;work:(650)633-6338
x-mozilla-html:FALSE
url:messaging.us.oracle.com
org:Oracle;Email Server
version:2.1
email;internet:[email-masked]
title:Senior Member of Technical Staff
adr;quoted-printable:;;600 Oracle Parkway=0D=0AM/S: 6op3;Redwood Shores;CA;94065;U.S.A
fn:Guang Yee
end:vcard

--------------8B518FEC5C6CAE5D1E8289D6--

Date: Tue, 21 Mar 2000 11:18:41 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: draft-ietf-smime-seclabel-00.txt
Cc: [email-masked]
Sender: [email-masked]

Weston:

I have two questions about the Internet-Draft.

QUESTION 1.

The Amoco policy defines confidentiality hierarchy and an integrity 
hierarchy.  In practice, is a piece of information marked with a 
confidentiality value, an integrity value, or both?  The ASN.1 defined in 
the document leads me to believe that a particular piece of information has 
either a confidentiality value or an integrity value, but never both.

You included the following ASN.1:
      Amoco-SecurityClassification ::=  {
        amoco general (6),
        amoco confidential (7),
        amoco highly confidential (8),
        amoco minimum (9),
        amoco medium (10),
        amoco maximum (11)  }

Since the classification in the ESS security label is a single INTEGER, 
only one of these values may be present in a particular instance of a 
security label.

Is the integrity value ever used to make an access control decision?  If 
not, then perhaps the integrity value should be carried in the privacy mark.

QUESTION 2.

In the Whirlpool section, you say:

      For WHIRLPOOL INTERNAL, additional markings or caveats are option at the
      discretion of the information owner.

      For WHIRLPOOL CONFIDENTIAL, add additional marking or caveats as 
necessary to
      comply with regulatory or heightened security 
requirements.  Examples:  MAKE NO
      COPIES, THIRD PARTY CONFIDENTIAL, ATTORNEY-CLIENT PRIVILEGED DOCUMENT,
      DISTRIBUTION LIMITED TO ____, COVERED BY A NON-ANALYSIS AGREEMENT.

The examples listed can be characterized as guidance to the information 
recipient about how the needs to be handled.  Mostly, guidance is provided 
about the redistribution of the information.  Since these are examples, I 
wonder if there is a example of a caveat on which one might expect 
automated access control.

Russ 

Date: Fri, 17 Mar 2000 09:31:43 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: S/MIME v3 Interoperability Testing (was RE: S/MIMEexamples draft )
Sender: [email-masked]

It occurs to me that this effort would be extremely useful in trying to 
further the interoperability testing that the PKI Forum is being set up 
to do.

What would be really great would be if we could go beyond examples, and
try to develop actual test cases.  Or maybe contribute test cases that we 
have developed internally.

As an example of the kind of obscure things that can bite you, I recently 
tried to gather up an entire set of encrypted correspondence by 
sending a encrypted message to myself with 30 or so encrypted attachments
that I dragged on to the attachment window.

Didn't work.  Only one message showed up in the attachments. So there's one 
bug to more to fix.

Why would you want to do such a thing?  For compactness and archiving ,
and perhaps to hide the plaintext headers that show who you were 
communicating with.

Bob

>>> Russ Housley <[email-masked]> 03/15/00 12:06PM >>>
John:

John, as S/MIME WG chairman, I greatly appreciate your commitment.  I hope 
that other implementors will join in this effort.  Collecting this data is 
essential for the specifications to progress from Proposed Standard to 
Draft Standard, so we might as well help implementors that come behind us.

Russ

At 09:45 AM 03/14/2000 -0500, Pawling, John wrote:
>Paul (and friends),
>
>We believe that the "Examples of S/MIME Messages" document should be
>enhanced and maintained.  We believe that it is extremely valuable to have a
>set of properly formatted sample S/MIME messages which can be used to test
>S/MIME implementations.  We have used the S/MIME Freeware Library (SFL) to
>successfully process (i.e. decode, verify, decrypt) the majority of the
>samples in the document.  I use the term "the majority" because the SFL does
>not support every S/MIME v3 optional feature.  For example, the SFL does not
>support the CMS authenticatedData content type.  We have also used the SFL
>to construct sample data (such as signed receipts) to be added to the
>document.  We have automated this SFL testing (through the use or test
>drivers and configuration files) so that it can be easily repeated and
>modified by us or independently by a third party (we provide all source
>code, unencumbered).  We are willing to spend time providing sample data to
>be included in the Examples document and to provide support when there are
>questions regarding the validity of the sample data.  We are also willing to
>participate in interoperability testing with others.
>
>We apologize for not providing feedback and submitting sample data sooner.
>We have been using the SFL to perform S/MIME v3 interoperability testing
>with Microsoft that has exercised the majority of the features specified by
>RFCs 2630 (CMS), 2631 (D-H) and 2634 (ESS).  This testing has included the
>RSA, mandatory S/MIME V3 and Fortezza suites of algorithms.  We were waiting
>until we finished interoperability testing with Microsoft to submit the
>SFL-produced sample data.  Yesterday (3/13/00) we successfully completed RFC
>2634 (ESS) signed receipt interoperability testing between the SFL and
>Microsoft.  This was the last major S/MIME v3 item that needed to be tested
>between the SFL and Microsoft.  We plan to provide sample signed receipts
>for inclusion in the Examples document.  We have also performed limited
>S/MIME v3 testing with Baltimore and Entrust.
>
>We still need to perform countersignature interoperability testing.  We plan
>to pursue this testing with Microsoft.  If anybody else can process
>countersignatures, please let us know.  We are not going to wait until this
>testing is done before submitting SFL-produced sample data for inclusion in
>the Examples document.
>
>As many of you know, Jim Schaad created a detailed set of matrices to
>document the interoperabilty testing performed between various
>implementations. There is a matrix for each S/MIME v3 specification.  These
>matrices are much more detailed than the "Examples of S/MIME Messages"
>document.  We have verified that the SFL can produce and process the
>majority of the features documented in the compliance matrices.  Again, I
>use the term "the majority" because the SFL does not support every S/MIME v3
>optional feature.  We have automated this SFL testing so that it can be
>easily repeated and modified by us or independently by a third party.  We
>have developed sample objects that illustrate each feature in the matrix
>that the SFL supports.
>
>Please note that Jim Schaad's matrices are a superset of the Examples
>document.  Does the group want to include all of Jim's tests in the Examples
>document?  If so, we can provide the sample data to illustrate each feature
>in the matrix that the SFL supports.  Please note that this document would
>be huge, but it would provide a comprehensive set of test data.  What do
>others think?
>
>We will have the SFL-produced test data ready for distribution by 24 March
>2000 at the latest.
>
>============================================
>John Pawling, Director - Systems Engineering
>J.G. Van Dyke & Associates, Inc;
>a Wang Government Services Company
>[email-masked] 
>============================================
>

From: =?UTF-8?B?UGF3bGluZywgSm9obg==?= <[email-masked]>
To: =?UTF-8?B?J0NhbWVyb24gU3RpbGxpb24n?= <[email-masked]>, =?UTF-8?B?J2lldGYtc21pbWVAaW1jLm9yZyc=?= <[email-masked]>
Cc: =?UTF-8?B?J3Bob2ZmbWFuQGltYy5vcmcn?= <[email-masked]>, =?UTF-8?B?QnJ5YW4gU3RhYXRz?= <[email-masked]>
Subject: =?UTF-8?B?UkU6IEVTUyA6IFNlY3VyZSBSZWNlaXB0IGVuY29kaW5nIHdpdGhp?= =?UTF-8?B?biBFbmNhcHN1bGF0ZWRDb250ZW50SW5mbw==?=
Date: Thu, 16 Mar 2000 13:41:23 -0500
Sender: [email-masked]

Cameron,
 
The signedData encapContentInfo eContent field is defined as an OCTET STRING
in RFC 2630 (CMS).   If the eContent field is present, then the OCTET STRING
tag and length octets must be present in the encoding of the signedData.
RFC 2630 Section 2 states: "As a general design philosophy, each content
type permits single pass processing using indefinite-length Basic Encoding
Rules (BER) encoding." and "Signed attributes and authenticated attributes
are the only CMS data types that require DER encoding."  Therefore, the
signedData content type (including the encapContentInfo eContent OCTET
STRING tag and length octets) does not need to be DER-encoded.  
 
As you correctly point out, RFC 2634 (ESS) requires that the Receipt content
type must be DER-encoded within the signedData encapContentInfo eContent
OCTET STRING.

============================================ 
John Pawling, Director - Systems Engineering 
J.G. Van Dyke & Associates, Inc; 
a Wang Government Services Company 
[email-masked] <mailto:[email-masked]>  
============================================ 

-----Original Message-----
From: Cameron Stillion [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Thursday, March 09, 2000 9:15 PM
To: [email-masked]' <mailto:[email-masked]'> 
Cc: [email-masked]'; Bryan Staats
Subject: ESS : Secure Receipt encoding within EncapsulatedContentInfo

... and now for something completely different:
 
According to the ESS RFC on page 16, step 9:
 
9.  The ASN.1 DER encoded Receipt content MUST be directly encoded within
the signedData encapContentInfo eContent OCTET STRING defined in [CMS].
 
Should eContent be a DER-encoding of the receipt?
    or
Should eContent be a DER-encoding of an OCTET STRING containing the
DER-encoding of the receipt?
 
The word "directly" seems to indicate that the former is the correct one.
Just tell me I'm not crazy.
 
Cameron Stillion

From: "Alexander" <[email-masked]>
To: "A good opportunity for u" <[email-masked]>
Date: Thu, 16 Mar 2000 12:51:29 +0100
Subject: Surfingprize brand new Get-paid-programm (very good)
Reply-To: [email-masked]
Sender: [email-masked]

SurfingPrizes:

A viewBar type that:
The referral structure is 5 levels deep:
For your surfing time, you'll receive $0.20 per hour;
for your direct referrals, you'll earn $0.04/hour;
and for your indirect referrals you'll earn $0.02/hour.
For 5 levels deep!

ViewBar Ver 1.0 Avalible for Win 95,98,NT

Site is well laid out and snappy.
I'm only number 786 in this one.

Sign-up Here: http://www.surfingprizes.com/r/?100786

Thanks for sign-up under me
Alexander 	[email-masked]  

From: =?utf-8?B?Q2FtZXJvbiBTdGlsbGlvbg==?= <[email-masked]>
To: =?utf-8?B?J2lldGYtc21pbWVAaW1jLm9yZyc=?= <[email-masked]>
Cc: =?utf-8?B?J3Bob2ZmbWFuQGltYy5vcmcn?= <[email-masked]>, =?utf-8?B?QnJ5YW4gU3RhYXRz?= <[email-masked]>
Subject: =?utf-8?B?RVNTIDogU2VjdXJlIFJlY2VpcHQgZW5jb2Rpbmcgd2l0aGluIEVu?= =?utf-8?B?Y2Fwc3VsYXRlZENvbnRlbnRJbmZv?=
Date: Thu, 9 Mar 2000 18:15:23 -0800 
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_000_01BF8F22.FC7C8624
Content-Type: text/plain;
	charset="utf-8"

... and now for something completely different:
 
According to the ESS RFC on page 16, step 9:
 
9.  The ASN.1 DER encoded Receipt content MUST be directly encoded within
the signedData encapContentInfo eContent OCTET STRING defined in [CMS].
 
Should eContent be a DER-encoding of the receipt?
    or
Should eContent be a DER-encoding of an OCTET STRING containing the
DER-encoding of the receipt?
 
The word "directly" seems to indicate that the former is the correct one.
Just tell me I'm not crazy.
 
Cameron Stillion

------_=_NextPart_000_01BF8F22.FC7C8624
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

------_=_NextPart_000_01BF8F22.FC7C8624--

Date: Wed, 15 Mar 2000 14:06:49 -0500
To: "Pawling, John" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: S/MIME v3 Interoperability Testing (was RE: S/MIME examples draft )
Cc: [email-masked]
Sender: [email-masked]

John:

John, as S/MIME WG chairman, I greatly appreciate your commitment.  I hope 
that other implementors will join in this effort.  Collecting this data is 
essential for the specifications to progress from Proposed Standard to 
Draft Standard, so we might as well help implementors that come behind us.

Russ

At 09:45 AM 03/14/2000 -0500, Pawling, John wrote:
>Paul (and friends),
>
>We believe that the "Examples of S/MIME Messages" document should be
>enhanced and maintained.  We believe that it is extremely valuable to have a
>set of properly formatted sample S/MIME messages which can be used to test
>S/MIME implementations.  We have used the S/MIME Freeware Library (SFL) to
>successfully process (i.e. decode, verify, decrypt) the majority of the
>samples in the document.  I use the term "the majority" because the SFL does
>not support every S/MIME v3 optional feature.  For example, the SFL does not
>support the CMS authenticatedData content type.  We have also used the SFL
>to construct sample data (such as signed receipts) to be added to the
>document.  We have automated this SFL testing (through the use or test
>drivers and configuration files) so that it can be easily repeated and
>modified by us or independently by a third party (we provide all source
>code, unencumbered).  We are willing to spend time providing sample data to
>be included in the Examples document and to provide support when there are
>questions regarding the validity of the sample data.  We are also willing to
>participate in interoperability testing with others.
>
>We apologize for not providing feedback and submitting sample data sooner.
>We have been using the SFL to perform S/MIME v3 interoperability testing
>with Microsoft that has exercised the majority of the features specified by
>RFCs 2630 (CMS), 2631 (D-H) and 2634 (ESS).  This testing has included the
>RSA, mandatory S/MIME V3 and Fortezza suites of algorithms.  We were waiting
>until we finished interoperability testing with Microsoft to submit the
>SFL-produced sample data.  Yesterday (3/13/00) we successfully completed RFC
>2634 (ESS) signed receipt interoperability testing between the SFL and
>Microsoft.  This was the last major S/MIME v3 item that needed to be tested
>between the SFL and Microsoft.  We plan to provide sample signed receipts
>for inclusion in the Examples document.  We have also performed limited
>S/MIME v3 testing with Baltimore and Entrust.
>
>We still need to perform countersignature interoperability testing.  We plan
>to pursue this testing with Microsoft.  If anybody else can process
>countersignatures, please let us know.  We are not going to wait until this
>testing is done before submitting SFL-produced sample data for inclusion in
>the Examples document.
>
>As many of you know, Jim Schaad created a detailed set of matrices to
>document the interoperabilty testing performed between various
>implementations. There is a matrix for each S/MIME v3 specification.  These
>matrices are much more detailed than the "Examples of S/MIME Messages"
>document.  We have verified that the SFL can produce and process the
>majority of the features documented in the compliance matrices.  Again, I
>use the term "the majority" because the SFL does not support every S/MIME v3
>optional feature.  We have automated this SFL testing so that it can be
>easily repeated and modified by us or independently by a third party.  We
>have developed sample objects that illustrate each feature in the matrix
>that the SFL supports.
>
>Please note that Jim Schaad's matrices are a superset of the Examples
>document.  Does the group want to include all of Jim's tests in the Examples
>document?  If so, we can provide the sample data to illustrate each feature
>in the matrix that the SFL supports.  Please note that this document would
>be huge, but it would provide a comprehensive set of test data.  What do
>others think?
>
>We will have the SFL-produced test data ready for distribution by 24 March
>2000 at the latest.
>
>============================================
>John Pawling, Director - Systems Engineering
>J.G. Van Dyke & Associates, Inc;
>a Wang Government Services Company
>[email-masked]
>============================================
>

From: "Pawling, John" <[email-masked]>
To: [email-masked]
Subject: S/MIME v3 Interoperability Testing (was RE: S/MIME examples draft )
Date: Tue, 14 Mar 2000 09:45:34 -0500
Sender: [email-masked]

Paul (and friends),

We believe that the "Examples of S/MIME Messages" document should be
enhanced and maintained.  We believe that it is extremely valuable to have a
set of properly formatted sample S/MIME messages which can be used to test
S/MIME implementations.  We have used the S/MIME Freeware Library (SFL) to
successfully process (i.e. decode, verify, decrypt) the majority of the
samples in the document.  I use the term "the majority" because the SFL does
not support every S/MIME v3 optional feature.  For example, the SFL does not
support the CMS authenticatedData content type.  We have also used the SFL
to construct sample data (such as signed receipts) to be added to the
document.  We have automated this SFL testing (through the use or test
drivers and configuration files) so that it can be easily repeated and
modified by us or independently by a third party (we provide all source
code, unencumbered).  We are willing to spend time providing sample data to
be included in the Examples document and to provide support when there are
questions regarding the validity of the sample data.  We are also willing to
participate in interoperability testing with others.

We apologize for not providing feedback and submitting sample data sooner.
We have been using the SFL to perform S/MIME v3 interoperability testing
with Microsoft that has exercised the majority of the features specified by
RFCs 2630 (CMS), 2631 (D-H) and 2634 (ESS).  This testing has included the
RSA, mandatory S/MIME V3 and Fortezza suites of algorithms.  We were waiting
until we finished interoperability testing with Microsoft to submit the
SFL-produced sample data.  Yesterday (3/13/00) we successfully completed RFC
2634 (ESS) signed receipt interoperability testing between the SFL and
Microsoft.  This was the last major S/MIME v3 item that needed to be tested
between the SFL and Microsoft.  We plan to provide sample signed receipts
for inclusion in the Examples document.  We have also performed limited
S/MIME v3 testing with Baltimore and Entrust. 

We still need to perform countersignature interoperability testing.  We plan
to pursue this testing with Microsoft.  If anybody else can process
countersignatures, please let us know.  We are not going to wait until this
testing is done before submitting SFL-produced sample data for inclusion in
the Examples document.

As many of you know, Jim Schaad created a detailed set of matrices to
document the interoperabilty testing performed between various
implementations. There is a matrix for each S/MIME v3 specification.  These
matrices are much more detailed than the "Examples of S/MIME Messages"
document.  We have verified that the SFL can produce and process the
majority of the features documented in the compliance matrices.  Again, I
use the term "the majority" because the SFL does not support every S/MIME v3
optional feature.  We have automated this SFL testing so that it can be
easily repeated and modified by us or independently by a third party.  We
have developed sample objects that illustrate each feature in the matrix
that the SFL supports.      

Please note that Jim Schaad's matrices are a superset of the Examples
document.  Does the group want to include all of Jim's tests in the Examples
document?  If so, we can provide the sample data to illustrate each feature
in the matrix that the SFL supports.  Please note that this document would
be huge, but it would provide a comprehensive set of test data.  What do
others think?

We will have the SFL-produced test data ready for distribution by 24 March
2000 at the latest.  

============================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc;
a Wang Government Services Company
[email-masked]
============================================ 

Date: Mon, 13 Mar 2000 20:20:38 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: S/MIME examples draft
Sender: [email-masked]

There has been essentially no input to this draft in a very long time. The 
vast majority of the input came from Jim Schaad, who is no longer in the 
S/MIME world. Thus, I believe that the draft is probably dead. If other 
S/MIME developers want to contribute examples where there are holes and 
comments for the examples that are there, I'm happy to continue the draft, 
but otherwise we might just let this go away.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 13 Mar 2000 14:33:51 -0800
To: [email-masked], [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: New draft on ASN.1 pitfalls
Sender: [email-masked]

Timing is everything. Just as the PKIX mailing list starts to talk about 
ASN.1 again, a new draft comes out that does a good job of listing some of 
the ASN.1 gotchas to look out for, as well as why ASN.1 isn't necessarily a 
great format to use (although it's a tad too late for that now...). Anyhow, 
take a look at 
<http://www.ietf.org/internet-drafts/draft-yu-asn1-pitfalls-00.txt>. The 
author said he's open to adding any PKIX-specific and S/MIME-specific 
warnings to the document.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 13 Mar 2000 15:15:34 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: LAST CALL:draft-ietf-smime-password-02.txt
Sender: [email-masked]

The Password-based Encryption for S/MIME specification is ready for Working 
Group Last Call.  Please post comments to the ietf-smime mail list before 
27 March 2000.

Russ

= = = = = = = = = =

	Title		: Password-based Encryption for S/MIME
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-smime-password-02.txt
	Pages		: 9
	Date		: 10-Mar-00
	
The Cryptographic Message Syntax data format doesn't currently contain
any provisions for password-based data encryption.  This document
provides a method of encrypting data using user-supplied passwords and,
by extension, any form of variable-length keying material which isn't
necessarily an algorithm-specific fixed-format key.

Date: Mon, 13 Mar 2000 10:43:16 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: S/MIME WG Agenda
Cc: [email-masked]
Sender: [email-masked]

             S/MIME Mail Security WG 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            Denis Pinkas
Wrap up                                 Russ Housley

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-password-02.txt
Date: Mon, 13 Mar 2000 06:19:38 -0500
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		: Password-based Encryption for S/MIME
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-smime-password-02.txt
	Pages		: 9
	Date		: 10-Mar-00
	
The Cryptographic Message Syntax data format doesn't currently contain
any provisions for password-based data encryption.  This document
provides a method of encrypting data using user-supplied passwords and,
by extension, any form of variable-length keying material which isn't
necessarily an algorithm-specific fixed-format key.

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-password-02.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-password-02.txt".

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cms-rsaes-oaep-00.txt
Date: Mon, 13 Mar 2000 06:19:33 -0500
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		: CMS RSAES-OAEP Conventions
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cms-rsaes-oaep-00.txt
	Pages		: 8
	Date		: 10-Mar-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-00.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-00.txt".

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-esformats-00.txt
Date: Fri, 10 Mar 2000 06:30:29 -0500
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		: Electronic Signature Formats for long term electronic 
                          signature
	Author(s)	: J. Ross, D. Pinkas, N. Pope
	Filename	: draft-ietf-smime-esformats-00.txt
	Pages		: 106
	Date		: 09-Mar-00
	
The informational RFC defines the format of an electronic signature 
that can remain valid over long periods. This includes evidence as to 
its validity even if the signer or verifying party later attempts to 
deny (repudiates) the validity of the signature.

The contents of this Informational RFC is technically equivalent to 
ETSI ES 201 733 V.1.1.1 Copyright (C). Individual copies of this 
ETSI deliverable can be downloaded from http://www.etsi.org

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-esformats-00.txt

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

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

--OtherAccess--

--NextPart--

From: "Jim Schaad" <[email-masked]>
Reply-to: [email-masked]
To: Aram Perez <[email-masked]>, [email-masked]
Date: Thu, 9 Mar 2000 23:18:29 +0800
Subject: RE: Triple Wrapping Survey
Sender: [email-masked]

>Hi Russ,
>
>I agree that S/MIMEv3 should minimize Base64 encoding when possible. As I
>understand MIME, all implementations should handle binary as this is the
>default unless otherwise specified.

There are some known existing implemenations which cannot correctly handle the
binary versions.  I do not know any longer how wide spread these versions are.

jim

>Regards,
>Aram Perez
>From: Russ Housley [mailto:[email-masked]]
>Sent: Monday, March 06, 2000 7:21 PM
>To: [email-masked]
>Subject: Triple Wrapping Survey
>
>
>I have a few questions for implementors.  First some background, then the 

>questions.
>
>The use of S/MIMEv3 Triple Wrapping leads to the incorporation of four MIME

>encodings.  If each of these encodings uses Base64, then the overhead is 
>huge.  I am interested in ways to reduce the overhead, hopefully without 
>hurting IMAP usability.
>
>1.  Can your implementation handle
>	MIME( SignedData (EnvelopedData (SignedData ( MIME ))) ?
>
>The outer SignedData has the OID for EnvelopedData in the content type, not

>id-data.
>The EnvelopedData has the OID for SignedData in the content type, not
>id-data.
>The inner Signed Data has the id-data OID in the content type.
>
>2.  Can your implementation handle MIME without Base64 encoding?  I am 
>interested in using "binary" instead of Base64 to reduce the overhead.
>
>Russ
>
>
http://www.nwlink.com

From: "Jim Schaad" <[email-masked]>
Reply-to: [email-masked]
To: Russ Housley <[email-masked]>, [email-masked]
Date: Thu, 9 Mar 2000 23:16:43 +0800
Subject: Re: Triple Wrapping Survey
Sender: [email-masked]

Msft versions cannot handle case #1 (I think).

Msft versions can handle case #2 without any problems.

jim schaad

>I have a few questions for implementors.  First some background, then the 

>questions.
>
>The use of S/MIMEv3 Triple Wrapping leads to the incorporation of four MIME

>encodings.  If each of these encodings uses Base64, then the overhead is 
>huge.  I am interested in ways to reduce the overhead, hopefully without 
>hurting IMAP usability.
>
>1.  Can your implementation handle
>	MIME( SignedData (EnvelopedData (SignedData ( MIME ))) ?
>
>The outer SignedData has the OID for EnvelopedData in the content type, not

>id-data.
>The EnvelopedData has the OID for SignedData in the content type, not id-data.

>The inner Signed Data has the id-data OID in the content type.
>
>2.  Can your implementation handle MIME without Base64 encoding?  I am 
>interested in using "binary" instead of Base64 to reduce the overhead.
>
>Russ
>
>
http://www.nwlink.com

Date: Thu, 09 Mar 2000 11:39:31 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: LAST CALL: draft-ietf-smime-cast-128-01.txt
Sender: [email-masked]

The CAST-128 algorithm specification is ready for Working Group Last 
Call.  Please post comments to the ietf-smime mail list before 23 March 2000.

Russ

= = = = = = = = = =

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 CAST-128 Encryption Algorithm in CMS
	Author(s)	: C. Adams
	Filename	: draft-ietf-smime-cast-128-01.txt
	Pages		: 6
	Date		: 03-Mar-00
	
This document specifies how to incorporate CAST-128 [RFC2144] into
the S/MIME Cryptographic Message Syntax (CMS) as an additional
algorithm for symmetric encryption.  The relevant OIDs and processing
steps are provided so that CAST-128 may be included in the CMS
specification [RFC2630] for symmetric content and key encryption.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-cast-128-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-cast-128-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-cast-128-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.
Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cast-128-01.txt

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-cast-128-01.txt> 

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-domsec-04.txt
Date: Thu, 09 Mar 2000 06:30:08 -0500
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		: Domain Security Services using S/MIME
	Author(s)	: T. Dean, W. Ottaway
	Filename	: draft-ietf-smime-domsec-04.txt
	Pages		: 8
	Date		: 08-Mar-00
	
This document describes how the S/MIME protocol can be processed and
generated by a number of components of a communication system, such as
message transfer agents, guards and gateways to deliver security
services. These services are collectively referred to as 'Domain
Security Services'. The mechanisms described in this document are
designed to solve a number of interoperability problems and technical
limitations that arise when different security domains wish to
communicate securely - for example when two domains use incompatible
messaging technologies such as X.400 and SMTP/MIME. This document is
also applicable to organisations and enterprises that have internal PKIs
which are not accessible by the outside world, but wish to interoperate
securely using the S/MIME protocol.

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

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Subject: RFC 2785 on Methods for Avoiding "Small-Subgroup" Attacks
Cc: [email-masked], [email-masked]
Date: Tue, 07 Mar 2000 15:26:53 -0800
From: RFC Editor <[email-masked]>
Sender: [email-masked]

--NextPart

A new Request for Comments is now available in online RFC libraries.

        RFC 2785

        Title:	    Methods for Avoiding the "Small-Subgroup" Attacks
                    on the Diffie-Hellman Key Agreement Method for
                    S/MIME 
        Author(s):  R. Zuccherato
        Status:     Informational
	Date:       March 2000
        Mailbox:    [email-masked]
        Pages:      11
        Characters: 24415
	Updates/Obsoletes/SeeAlso: None
        I-D Tag:    draft-ietf-smime-small-subgroup-03.txt

        URL:        ftp://ftp.isi.edu/in-notes/rfc2785.txt

In some circumstances the use of the Diffie-Hellman key agreement
scheme in a prime order subgroup of a large prime p is vulnerable to
certain attacks known as "small-subgroup" attacks.  Methods exist,
however, to prevent these attacks.  This document will describe the
situations relevant to implementations of S/MIME version 3 in which
protection is necessary and the methods that can be used to prevent
these attacks. 

This document is a product of the S/MIME Mail Security Working Group
of the IETF.

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--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]>

RETRIEVE: rfc
DOC-ID: rfc2785

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc2785.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

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

--OtherAccess--
--NextPart--

From: "Blake Ramsdell" <[email-masked]>
To: "'Aram Perez'" <[email-masked]>, [email-masked]
Subject: RE: Triple Wrapping Survey
Date: Tue, 7 Mar 2000 12:26:58 -0800
Sender: [email-masked]

I think that the point Russ was making is "can you handle nesting of CMS
objects" not "can you handle nesting of MIME wrapped CMS objects".  In our
case, we can only do MIME wrapped CMS objects, but we can handle binary
encoding of those objects.

Blake

-----Original Message-----
From: Aram Perez [mailto:[email-masked]]
Sent: Tuesday, March 07, 2000 6:30 AM
To: [email-masked]
Subject: RE: Triple Wrapping Survey

Hi Russ,

I agree that S/MIMEv3 should minimize Base64 encoding when possible. As I
understand MIME, all implementations should handle binary as this is the
default unless otherwise specified.

Regards,
Aram Perez

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Monday, March 06, 2000 7:21 PM
To: [email-masked]
Subject: Triple Wrapping Survey

I have a few questions for implementors.  First some background, then the 
questions.

The use of S/MIMEv3 Triple Wrapping leads to the incorporation of four MIME 
encodings.  If each of these encodings uses Base64, then the overhead is 
huge.  I am interested in ways to reduce the overhead, hopefully without 
hurting IMAP usability.

1.  Can your implementation handle
	MIME( SignedData (EnvelopedData (SignedData ( MIME ))) ?

The outer SignedData has the OID for EnvelopedData in the content type, not 
id-data.
The EnvelopedData has the OID for SignedData in the content type, not
id-data.
The inner Signed Data has the id-data OID in the content type.

2.  Can your implementation handle MIME without Base64 encoding?  I am 
interested in using "binary" instead of Base64 to reduce the overhead.

Russ

From: Aram Perez <[email-masked]>
To: [email-masked]
Subject: RE: Triple Wrapping Survey
Date: Tue, 7 Mar 2000 09:29:31 -0500 
Sender: [email-masked]

Hi Russ,

I agree that S/MIMEv3 should minimize Base64 encoding when possible. As I
understand MIME, all implementations should handle binary as this is the
default unless otherwise specified.

Regards,
Aram Perez

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Monday, March 06, 2000 7:21 PM
To: [email-masked]
Subject: Triple Wrapping Survey

I have a few questions for implementors.  First some background, then the 
questions.

The use of S/MIMEv3 Triple Wrapping leads to the incorporation of four MIME 
encodings.  If each of these encodings uses Base64, then the overhead is 
huge.  I am interested in ways to reduce the overhead, hopefully without 
hurting IMAP usability.

1.  Can your implementation handle
	MIME( SignedData (EnvelopedData (SignedData ( MIME ))) ?

The outer SignedData has the OID for EnvelopedData in the content type, not 
id-data.
The EnvelopedData has the OID for SignedData in the content type, not
id-data.
The inner Signed Data has the id-data OID in the content type.

2.  Can your implementation handle MIME without Base64 encoding?  I am 
interested in using "binary" instead of Base64 to reduce the overhead.

Russ

Date: Mon, 06 Mar 2000 19:21:17 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Triple Wrapping Survey
Sender: [email-masked]

I have a few questions for implementors.  First some background, then the 
questions.

The use of S/MIMEv3 Triple Wrapping leads to the incorporation of four MIME 
encodings.  If each of these encodings uses Base64, then the overhead is 
huge.  I am interested in ways to reduce the overhead, hopefully without 
hurting IMAP usability.

1.  Can your implementation handle
	MIME( SignedData (EnvelopedData (SignedData ( MIME ))) ?

The outer SignedData has the OID for EnvelopedData in the content type, not 
id-data.
The EnvelopedData has the OID for SignedData in the content type, not id-data.
The inner Signed Data has the id-data OID in the content type.

2.  Can your implementation handle MIME without Base64 encoding?  I am 
interested in using "binary" instead of Base64 to reduce the overhead.

Russ

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cast-128-01.txt
Date: Mon, 06 Mar 2000 06:56:48 -0500
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 CAST-128 Encryption Algorithm in CMS
	Author(s)	: C. Adams
	Filename	: draft-ietf-smime-cast-128-01.txt
	Pages		: 6
	Date		: 03-Mar-00
	
This document specifies how to incorporate CAST-128 [RFC2144] into 
the S/MIME Cryptographic Message Syntax (CMS) as an additional  
algorithm for symmetric encryption.  The relevant OIDs and processing 
steps are provided so that CAST-128 may be included in the CMS 
specification [RFC2630] for symmetric content and key encryption.

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

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

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

--OtherAccess--

--NextPart--

From: "Teiwes, Stephan (iT_SEC)" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, [email-masked]
Subject: RE: draft-ietf-smime-idea
Date: Fri, 3 Mar 2000 18:53:48 +0100 
Sender: [email-masked]

Firstly, I would like to apologize for the delay of my response (I was busy
on CeBIT).

We highly respect all comments on the draft and would like to proceed in the
following way:

1. we will submit an IPR statement to the IETF and this working group very
soon

2. we will remove all sentences in the draft which could lead to the
impression of marketing; it is not our intention to misuse the draft for
marketing purposes

I would like to remark that the sentence "Organization who make already use
of IDEA for other applications also want to use IDEA in S/MIME." has been
introduced for justification. We sent already an long list of IDEA users in
industry to the SMIME working group (also Mr. Hoffman got this list, and
thus he should not say that he has never heart of anyone wanting to use
IDEA). We can proove that IDEA is widely used in Europe. According to our
experience customers in industry often like to choose a symmetric cipher as
a part of their security policy. This demand should be considered in SMIME,
and that's why we wrote the draft. 

3. The short statement and reference on the security of IDEA has been
introduced in appendix B when Mr. Hoffman asked us to include such a
statement (after submission of draft verion 0). Basically, we reacted on his
doubts about the IDEA security. Anyway, we will remove the statement
"Experts in cryptography consider IDEA to be a highly secure symmetric
cipher [IDEA]" as it can be directly obtained from the stated literature.

Despite different personal opinions about the use of IDEA, we believe, the
customer's desires should be considered. We can proove that big European
companies and banks are using it, and they want to use it in SMIME as well. 

Thanks a lot for your understanding and support.

*Stephan Teiwes, iT_Security AG

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Mittwoch, 23. Februar 2000 20:20
To: [email-masked]
Subject: Re: draft-ietf-smime-idea

All:

Paul raises some very important points.  Let me share my view as the S/MIME 
Working Group Chair.

1.  We must have an IPR statement for this document to progress to an RFC.

2.  I do not mind some justification text.  Something like: "Organization 
who make already use of IDEA for other applications also want to use IDEA 
in S/MIME."  But, in my opinion, the marketing hype needs to be 
significantly reduced.  The CAST-128 document does not try to convince 
anyone that CAST-128 is appropriate or inappropriate for any particular 
group of users.  The IDEA document should have a similar tone.

3.  I would like this document to become a Standards Track document.  The 
document should state the one and only way that IDEA is used with 
CMS.  Clearly, IDEA will not be mandatory to implement, but if IDEA is 
implemented, then it MUST be done in the manner specified in this 
document.  I cannot recommend that this document become a Standards Track 
RFC until items 1 and 2 are repaired.

Russ

At 09:58 AM 02/23/2000 -0800, Paul Hoffman / IMC wrote:
>There are a few things in this document that should raise concern.
>
>Appendix C states clearly that this is a patented algorithm for which 
>licensing is available. However, it appears that no one has let the IETF 
>Secretariat know that. Nothing about IDEA is listed on 
><http://www.ietf.org/ipr.html>. This draft should not be considered until 
>there is a formal statement to the IETF.
>
>Parts of the document sounds like a marketing brochure. "Today, IDEA is 
>widely applied in electronic business applications." "Especially for those 
>organization who make already use of IDEA on a wide scale it is of high 
>interest that IDEA is also available in S/MIME." "Experts in cryptography 
>consider IDEA to be a highly secure symmetric cipher [IDEA]." And so on.
>
>These seem particularly inappropriate for an RFC. To be frank, I've never 
>heard of anyone wanting to use IDEA for anything other than old PGP. The 
>folks who wrote PGP had their reasons for choosing IDEA when they did, but 
>they dropped IDEA as a required algorithm for OpenPGP and that doesn't 
>appear to have negatively affected them. The IETF shouldn't codify this 
>kind of marketing hype, even in an Informational RFC. To move forwards 
>with this, it would be nice if the authors went through the draft and took 
>out the marketing fluff.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium

From: "Peter Lipp" <[email-masked]>
To: <[email-masked]>
Subject: AW: draft-ietf-smime-idea
Date: Fri, 3 Mar 2000 15:36:36 +0100
Importance: Normal
Sender: [email-masked]

This is a multipart MIME message, it may require a MIME capable user agent.
----IAIK.SMIME.MAPPER.90086585--
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

> In fact, I think there are already FAR too many algorithms,
> variations, etc., in the  S/MIME standard as
> it is, and to virtually no good purpose that I can see.
Yes! As long as there is a strong enough free cipher in there, everybody
should be happy. Maybe another one to choose from, and yes, as AES becomes a
standard, there will be a need to add it(them).

What do the ton's of ciphersuites in TLS buy us if there are major vendors
only supporting the RSA ones and all the products need to be able to talk to
them? Yes, we can say "all ciphersuites implemented in our toolkit"!

Peter
______________________________________
Dr. Peter Lipp
IAIK, TU Graz
Inffeldgasse 16a, A-8010 Graz, Austria
Tel: +43 316 873 5513
Fax: +43 316 873 5520
Web: www.iaik.at

----IAIK.SMIME.MAPPER.90086585--
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

AAAAAAAA
----IAIK.SMIME.MAPPER.90086585----