REVERSE the AGING PROCESS 10-20 Years!

[[e-mail]]

HAVE YOU HEARD OF HUMAN GROWTH HORMONE (HGH)???

Released by your own pituitary gland, HGH starts
declining in your 20s, even more in your 30s and 40s,
eventually resulting in the shrinkage of major
organs-plus all other symptoms related to old age.

THIS CAN NOW BE REVERSED!!! IN THOUSANDS OF CLINICAL
STUDIES, HGH HAS BEEN SHOWN TO ACCOMPLISH THE FOLLOWING:

* Reduce Body Fat Without Dieting
   Build Lean Muscle WITHOUT EXERCISE!

* Enhance Sexual Performance

* Remove Wrinkles and Cellulite

* Lower Blood Pressure and improve Cholesterol Profile

* Improve Sleep, Vision and Memory

* Restore Hair Color and Growth

* Strengthen the Immune System

* Increase Energy and Cardiac Output

* Turn back your body's Biological Time Clock 10-20
   years in 6 months of usage !!!

You don't have to spend thousands of dollars on shots.
You don't have to spend the $139.00 per bottle that
HGH is selling for at some Clinics in the
United States.

For the next 30 Days, you can obtain a complete
one-month supply of our HGH releaser for our special
"New Customers" price of just $69.95 plus $6.00
shipping and handling. To ensure a constant supply and
to SAVE EVEN MORE, you can order with confidence
3 bottles of HGH and GET 1 FREE - that's just $209.85 for
4 bottles, plus $6.00 shipping and handling.
You SAVE $69.95! ORDER TODAY!

Payment Methods

You may FAX or Postal Mail Checks, MasterCard, Visa,
& American Express payments. Money Orders
are accepted only by Postal Mail.


Step 1: Place a check by your desired quanity.


______ 1 Bottle of HGH $69.95


______ 2 Bottles of HGH $131.90 ($65.95 a bottle)


______ 4 Bottles of HGH (Buy 3 get 1 FREE. SAVE $69.95) $209.85


Please add $6 shipping and handling for any size order.
[ Total cost including shipping & handling,
1 bottle=$75.95, 2 bottles=$137.90, 4 bottles=$215.85 ]

International shipping, please add $35 for any size order
[ Total cost including shipping & handling,
1 bottle=$104.95, 2 bottles=$166.90, 4 bottles=$244.85 ]
Foreign checks are not accepted.  Credit cards & international
money orders only.

Step 2: Place a check by your desired payment method
and complete fields if necessary.


_____Check or CHECK-BY-FAX [details below]


_____Money Order


_____American Express
Account Number__________________ Exp____/____

_____Visa
Account Number__________________ Exp____/____

_____MasterCard
Account Number__________________ Exp____/____


Please make your check or money order payable to
"Lion Sciences National".

Step 3: Please complete and print the following fields clearly.


Name ___________________________________________________


Address _________________________________________________


City ____________________________________________________


State ___________________________________________________


Zip _____________________________________________________


E-mail __________________________________________________


Signature _________________________________________________
[ required for check and credit card orders]



            Toll Free FAX Order Line: 1-800-940-6590

If faxing in your order, please state whether you require
a fax, email, or no confirmation at all.
Allow up to one day for confirmation, if requested.
FAX orders are processed immediately.

            Or, print & mail to:

Lion Sciences National
273 S. State Rd. 7  #193
Margate, FL 33068-5727


        ______________________________________________________


*CHECK BY FAX ORDERS: Complete the check as normal. Tape
the check in the area below. Below the check, clearly write
the check number, all numbers at the bottom of the check,
& your name. Tape the check below and fax the check to the
toll free FAX number above. Void the check. Our merchant
will electronically debit your account for the amount of
the check; your reference number for this transaction will
be your check number. Nothing could be safer & easier !

                          TAPE CHECK BELOW
















_____________________________________________________________

This is a one time mailing: Removal is automatic and no further
contact is necessary. Please Note: HGH is not intended to
diagnose, treat, cure or prevent any disease. The FDA has not
evaluated these statements.



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA24111 for ietf-smime-bks; Thu, 30 Nov 2000 15:43:05 -0800 (PST)
Received: from dns.wsbx.com ([202.99.11.67]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA24107 for <[e-mail]>; Thu, 30 Nov 2000 15:43:04 -0800 (PST)
Date: Thu, 30 Nov 2000 15:43:04 -0800 (PST)
From: [e-mail]
Message-Id: <[e-mail]>
Received: from aks011 (1Cust54.tnt1.mia5.da.uu.net [63.30.194.54]) by dns.wsbx.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id X703J4LZ; Fri, 1 Dec 2000 07:47:20 +0800
To: [e-mail]
Subject: REVERSE the AGING PROCESS 10-20 Years!
MIME-Version: 1.0
Content-Type: text/plain; charset=unknown-8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

HAVE YOU HEARD OF HUMAN GROWTH HORMONE (HGH)???

Released by your own pituitary gland, HGH starts
declining in your 20s, even more in your 30s and 40s,
eventually resulting in the shrinkage of major
organs-plus all other symptoms related to old age.

THIS CAN NOW BE REVERSED!!! IN THOUSANDS OF CLINICAL
STUDIES, HGH HAS BEEN SHOWN TO ACCOMPLISH THE FOLLOWING:

* Reduce Body Fat Without Dieting
   Build Lean Muscle WITHOUT EXERCISE!

* Enhance Sexual Performance

* Remove Wrinkles and Cellulite

* Lower Blood Pressure and improve Cholesterol Profile

* Improve Sleep, Vision and Memory

* Restore Hair Color and Growth

* Strengthen the Immune System

* Increase Energy and Cardiac Output

* Turn back your body's Biological Time Clock 10-20
   years in 6 months of usage !!!

You don't have to spend thousands of dollars on shots.
You don't have to spend the $139.00 per bottle that
HGH is selling for at some Clinics in the
United States.

For the next 30 Days, you can obtain a complete
one-month supply of our HGH releaser for our special
"New Customers" price of just $69.95 plus $6.00
shipping and handling. To ensure a constant supply and
to SAVE EVEN MORE, you can order with confidence
3 bottles of HGH and GET 1 FREE - that's just $209.85 for
4 bottles, plus $6.00 shipping and handling.
You SAVE $69.95! ORDER TODAY!

Payment Methods

You may FAX or Postal Mail Checks, MasterCard, Visa,
& American Express payments. Money Orders
are accepted only by Postal Mail.


Step 1: Place a check by your desired quanity.


______ 1 Bottle of HGH $69.95


______ 2 Bottles of HGH $131.90 ($65.95 a bottle)


______ 4 Bottles of HGH (Buy 3 get 1 FREE. SAVE $69.95) $209.85


Please add $6 shipping and handling for any size order.
[ Total cost including shipping & handling,
1 bottle=$75.95, 2 bottles=$137.90, 4 bottles=$215.85 ]

International shipping, please add $35 for any size order
[ Total cost including shipping & handling,
1 bottle=$104.95, 2 bottles=$166.90, 4 bottles=$244.85 ]
Foreign checks are not accepted.  Credit cards & international
money orders only.

Step 2: Place a check by your desired payment method
and complete fields if necessary.


_____Check or CHECK-BY-FAX [details below]


_____Money Order


_____American Express
Account Number__________________ Exp____/____

_____Visa
Account Number__________________ Exp____/____

_____MasterCard
Account Number__________________ Exp____/____


Please make your check or money order payable to
"Lion Sciences National".

Step 3: Please complete and print the following fields clearly.


Name ___________________________________________________


Address _________________________________________________


City ____________________________________________________


State ___________________________________________________


Zip _____________________________________________________


E-mail __________________________________________________


Signature _________________________________________________
[ required for check and credit card orders]



            Toll Free FAX Order Line: 1-800-940-6590

If faxing in your order, please state whether you require
a fax, email, or no confirmation at all.
Allow up to one day for confirmation, if requested.
FAX orders are processed immediately.

            Or, print & mail to:

Lion Sciences National
273 S. State Rd. 7  #193
Margate, FL 33068-5727


        ______________________________________________________


*CHECK BY FAX ORDERS: Complete the check as normal. Tape
the check in the area below. Below the check, clearly write
the check number, all numbers at the bottom of the check,
& your name. Tape the check below and fax the check to the
toll free FAX number above. Void the check. Our merchant
will electronically debit your account for the amount of
the check; your reference number for this transaction will
be your check number. Nothing could be safer & easier !

                          TAPE CHECK BELOW
















_____________________________________________________________

This is a one time mailing: Removal is automatic and no further
contact is necessary. Please Note: HGH is not intended to
diagnose, treat, cure or prevent any disease. The FDA has not
evaluated these statements.


Received: by ns.secondary.com (8.9.3/8.9.3) id HAA18919 for ietf-smime-bks; Thu, 30 Nov 2000 07:20:03 -0800 (PST)
Received: from smtp-a.capu.net (IDENT:[e-mail] [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18912 for <[e-mail]>; Thu, 30 Nov 2000 07:20:02 -0800 (PST)
Received: from ieca.com (mva-aa-044.capu.net [207.226.159.44]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id KAA20188; Thu, 30 Nov 2000 10:21:32 -0500
Message-ID: <[e-mail]>
Date: Thu, 30 Nov 2000 10:21:32 -0500
From: "Bonatti, Chris" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Enzo Michelangeli <[e-mail]>
CC: Bob Jueneman <[e-mail]>, [e-mail]
Subject: Re: RSA vs. DSA MUST
References: <[e-mail]> <008701c05a85$245f00d0$6000a8c0@em>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Enzo Michelangeli wrote:

> Here is my modest proposal for SMIME v.3 sole MUST requirements:
>
> - Full interoperability with SMIME v.2, therefore #include-ing all the MUST
> of RFC2311;
> - Minimum key length raised to 1024-bit for PK and 112-bit for symmetric
> algorithms;
> - At least one other key exchange algorithm and one signature algorithm
> unrelated to the problem of modular factorization, to protect against
> possible unpleasant effects of progress in numbers theory. I'd say that DSA
> and DH are the best candidates, if we want to exorcise the IP curse that
> could strike ECC-based techniques;
> - 3DES-EDE and Rijndael added to RC2.
>
> Cheers --
>
> Enzo

Enzo,

This isn't actually too modest in my view.  In terms of numbers of things
supported it's not too far from where we are now (just a few attributes).  I
would support this with one addition.  I think you *need* to support the
'SMIMECapabilities' on reception.  This just seems like a necessity in any
environment that supports multiple algorithms.  Otherwise, you have all you need
for basic interoperability.

Chris





Received: by ns.secondary.com (8.9.3/8.9.3) id HAA18892 for ietf-smime-bks; Thu, 30 Nov 2000 07:19:52 -0800 (PST)
Received: from smtp-a.capu.net (IDENT:[e-mail] [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18885 for <[e-mail]>; Thu, 30 Nov 2000 07:19:51 -0800 (PST)
Received: from ieca.com (mva-aa-044.capu.net [207.226.159.44]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id KAA20162; Thu, 30 Nov 2000 10:21:23 -0500
Message-ID: <[e-mail]>
Date: Thu, 30 Nov 2000 10:21:23 -0500
From: "Bonatti, Chris" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dr S N Henson <[e-mail]>
CC: [e-mail]
Subject: Re: RSA vs. DSA MUST
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dr S N Henson wrote:

> "Bonatti, Chris" wrote:
> >
> >     Reading through this thread, I am astonished at a couple of apparent truisms that are emerging from the various earnest statements made.  These are (employing a little editorial license):
> >
> >    * The implementation cost of DSA/D-H/3DES was acceptable when RSA was patented, but now that some of us have actually built/tested this the cost has gone up into the "too high" range.
> >
>
> I'd say in the DH case (and to some extent DSA) there's the issue of how
> practical it is. The only DH certificates I've ever seen were in the
> S/MIME examples draft. I suspect there are problems with the parameters
> but despite repeated queries I never found anyone who could
> independently check them.
>

I agree about D-H certs.  They are not deployed as far as I can see.


>
> If public CAs issuing DSA certificates are rare then I'd say CAs issuing
> DH certificates are virtually non existent. Does anyone know of a single
> example?
>

For "public CAs" I'd have to agree.  I think the US government has issued *lots* of DSA certs, but they generally don't emit them because the interoperability picture is rather bleak.  I don't
think secure mail gets used much outside of fairly closed environments for this very reason.  It's exceedingly rare that I even see a signed message in this forum.


>
> Its all very nice adding support for DSA and DH but if users can't get
> any certificates from public CAs then their value is severely limited.
>

It's a bit of a chicken and egg problem, though.

Chris



>
> Steve.
> --
> Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
> Personal Email: [e-mail]
> Senior crypto engineer, Celo Communications: http://www.celocom.com/
> Core developer of the   OpenSSL project: http://www.openssl.org/
> Business Email: [e-mail] PGP key: via homepage.



Received: by ns.secondary.com (8.9.3/8.9.3) id HAA18835 for ietf-smime-bks; Thu, 30 Nov 2000 07:19:26 -0800 (PST)
Received: from smtp-a.capu.net (IDENT:[e-mail] [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18829 for <[e-mail]>; Thu, 30 Nov 2000 07:19:25 -0800 (PST)
Received: from ieca.com (mva-aa-044.capu.net [207.226.159.44]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id KAA20115; Thu, 30 Nov 2000 10:21:00 -0500
Message-ID: <[e-mail]>
Date: Thu, 30 Nov 2000 10:21:00 -0500
From: "Bonatti, Chris" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Rich Salz <[e-mail]>
CC: [e-mail]
Subject: Re: RSA vs. DSA MUST
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Rich Salz wrote:

> To be algorithm independant, you make sure you always identify the algorithm,
> and don't mistakenly say "encrypted data" without specifying the mechanism.
> During development of the standards, a good way to do that is to make sure
> multiple mechanisms are specified. In this case, the theoretical (DSA) and the
> practical (RSA).
>

I had the sense that what Dave was alluding to was something more.  It sounds like
an algorithm independent infrastructure, or maybe a multi-algorithm infrastructure
is a better way to say it.  (Dave, I don't want to put words in your mouth, but it
seemed to me this is what your 11/28 message was saying.)  This strikes me as a
good idea from a robustness point of view as has already been stated.  It seems
like we're saying on the one hand that this is a good idea, yet on the other that
everybody building to a lowest common denominator is all we're willing to do.
That seems a little disconnected to me.


>
> Peter Gutman said it best a few weeks ago, shortly after RSA expired.
> Something along the lines of "we all pretended to do DSA, but in reality
> everyone did RSA."  For political reasons, the IETF bent over backwards to
> avoid mandating patented technology.
>

I missed this statement the first time around, but I think it's probably
accurate.  However, consider just what it says about IETF's overall impact on
industry.  I think we take the whole MUST/SHOULD/MAY debate way too seriously.
Industry does what it wants.


>
> >Personally, I favor products that support LOTS of interoperability modes.
>
> That's nonsensical.  Do you prefer BER over DER? :)
>

For some things, yes.  It's better for one-pass processing for instance.

>
> The marketplace has decided and the common crypto mechanism is RSA, and
> practically nobody cares about DSA.  Certainly, making DSA not MUST will not
> hurt the DSA-using community.
>
> It's not the IETF's job to raise the bar.  It's the IETF's job to make sure we
> all speak the same language, and clearly that language is mod-exp.
>         /r$

I agree on these points.


Cheers,
Chris B.





Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA18825 for ietf-smime-bks; Thu, 30 Nov 2000 07:19:25 -0800 (PST)
Received: from smtp-a.capu.net (IDENT:[e-mail] [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18815 for <[e-mail]>; Thu, 30 Nov 2000 07:19:22 -0800 (PST)
Received: from ieca.com (mva-aa-044.capu.net [207.226.159.44]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id KAA20102; Thu, 30 Nov 2000 10:20:56 -0500
Message-ID: <[e-mail]>
Date: Thu, 30 Nov 2000 10:20:51 -0500
From: "Bonatti, Chris" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: [e-mail]
Subject: Re: RSA vs. DSA MUST
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob,

Did I mention that sticking my arm into hornets nests is one of my favorite hobbies. ;-)  This nest look good and ripe...

Bob Jueneman wrote:

> Chris, I believe these points are important, and perhaps more important than the particular issues at hand.  So please allow me to wax philosophical.
>
> As a consumer, all things being equal, I like products that support lots of interoperability modes too.  Beer, champagne, hot dogs, filet mignon, ice cream, apple pie, floor wax and desert topping -- they're all great, at least if you can afford them.
>
> But as a vendor, I am increasingly concerned about the amount of feature creep that we are seeing every day in both the PKIX and SMIME groups, apparently  almost unconstrained by business requirements.  We need interoperability, and that should not mean lowest common denominator, but it also shouldn't mean being all things to all men.
>

I think that most of the "feature creep" to which you refer is in the realm of options.  There is still a fairly small core of S/MIME features that are MUSTs, and nearly all of them have some core interoperability reason.

<snip>

>
> Now allow me to (gently, I hope) take issue with some of your other statements:
> >
> >   * The implementation cost of DSA/D-H/3DES was acceptable when RSA was patented, but now that some of us have actually built/tested this the cost
> >has gone up into the "too high" range.
>
> I would disagree.  The cost of the RSA license was minimal relative to other development costs, and the RSA algorithm was effectively all there was in terms of deployed PKI infrastructure.  The fact that DSA and D-H were labeled MUST was chalked up to IETF politics, and completely ignored by the vendor community as not being worth the implementation cost in terms of revenue return. Granted, it didn't meet some of the expressed desires of the US Government, but the USG has always had a much bigger appetite than budget.  (Remember Jovial?  Ada?  C2 by '92?)  Money talks, and everything else walks.  They imposed requirements, but those requirements didn't stick when it came to real procurements.
>

Okay, but you're arguing against something that I'm not saying.  I'm not saying that anything should be MUST (in fact, I think the reverse should be the case).

I am also NOT saying that we should implement these algorithms because the government says so (like Ada, etc.).  What I'm saying is that two years ago WE said is was good enough, cheap enough, etc.  Now suddenly it isn't.  What gives.  I'm trying to point out some intellectual disingenuousness, not arguing for an end state.


> >
> >   * Specifying a single MUST algorithm suite was sufficient to make S/MIME algorithm independent, but actually requiring two algorithms suites will cost too
> >much.  If we've really achieved algorithm independence in the sense that Dave Kemp suggests, this should be a debate about a relatively small math module.
>
> No, again I disagree.  The math module isn't the problem.  As a BSAFE licensee, we already have all of the math modules we would need.  The real issue is all of the multitudinous GUI screens that have to be developed to allow the user to choose this, that or the other algorithm within S/MIME, and then the same set of choices in any PKI products, and then testing all of these options in every conceivable combination, not just within a given product but in combination with all of the other leading e-mail packages, plus the various PKI services and toolkits as well.  those costs dwarf the cost of the math module by a couple of orders of magnitude.
>

This seems a little overstated.  As a developer, surely you have the latitude to design your GUIs the way you want.  That doesn't stop you from supporting whatever algorithms you want, or auto-selecting based on the 'SMIMECapabilities'.


>
> >   * We have an 'SMIMECapabilities' attribute for which support is MUST, but some implementations ignore it so we have to use the lowest common
> >denominator to force interoperability.  What make anybody think a MUST on an algorithm choice would be taken any more seriously?
>
> Two issues.  As I recall, the SMIMECapabilities is a MAY, not a MUST, although I'll stand corrected if I'm wrong.  And as I say, and Peter Gutmann said more succinctly, MUST matters if and only if the vendor was inclined to implement that option anyway.  It might be sufficient to push someone over the fence who was already 49% there, but not much more.  Standards compliance doesn't pay the rent -- customers do.
>

The 'SMIMECapabilities' attribute is a MUST on reception, and a SHOULD on origination.

On your second point, you have zeroed in on the point of my third bullet admirably.  If the MUST doesn't mean much, why are we debating it like it's a meaningful decision?


> >
> >    I don't think I actually have an opinion on this issue myself.  I'm of the mind set to mandate nothing and let Darwin decide.  However, I find the seeming
> >illogic of these collective opinions very troubling.  It leads me to think that we're not getting to the REAL reasoning behind this move.
> >
> >    I think Blake was closest to this in stating that there has been no customer demand for DSA.  Is this the REAL reason to dump DSA?  Are customers
> >demanding RSA be used?  Do customers express demand for any algorithms, or do they just want it to be "secure"?  Are we just drifting to the path of least
> >resistance?
>
> Customers don't demand or specify algorithms.  They just want it to be secure, and trust that the vendor will figure out what that means.  What they do insist on, however, is that the product work well with the existing infrastructure in order to reduce their total overall cost of ownership.  The more sophisticated customers realize that adding more and more features that they never use significantly increases that TCO, so overburdening a product with unnecessary features causes a significant backlash.  Increased cost of development with decreased sales.  What a concept!
>

However, by this logic nothing ever improves.  I'm not knowledgable enough to say whether DSA/D-H is an *improvement* over RSA, or just another choice.  Nevertheless, I think this evaluation should be a factor.  Somebody else asked the question too.  (?)  Is DSA/D-H better?  If not, then its okay to stick with what's out there.  If is it, then we've got to decide if it's better enough to be worth upgrading the infrastructure.  I have not even heard this point raised yet.  Why not?

All the best,
Chris sends...





Received: by ns.secondary.com (8.9.3/8.9.3) id CAA27612 for ietf-smime-bks; Thu, 30 Nov 2000 02:56:09 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA27592 for <[e-mail]>; Thu, 30 Nov 2000 02:56:06 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28262; Thu, 30 Nov 2000 05:57:39 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-esformats-02.txt
Date: Thu, 30 Nov 2000 05:57:38 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Electronic Signature Formats for long term electronic 
                          signature
	Author(s)	: D. Pinkas, J. Ross, N. Pope
	Filename	: draft-ietf-smime-esformats-02.txt
	Pages		: 75
	Date		: 29-Nov-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 (i.e. repudiates, see [ISONR]) the validity of the signature.
The format can be considered as an extension to RFC 2630 [CMS] and RFC 
2634 [ESS], where, when appropriate additional signed and unsigned 
attributes have been defined.
The contents of this Informational RFC is technically equivalent to 
ETSI ES 201 733 V.1.1.3 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-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-esformats-02.txt".

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id UAA28359 for ietf-smime-bks; Wed, 29 Nov 2000 20:21:17 -0800 (PST)
Received: from china.asiainter.net (asiainter.net [202.84.207.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA28354 for <[e-mail]>; Wed, 29 Nov 2000 20:21:15 -0800 (PST)
Received: (qmail 1233 invoked from network); 30 Nov 2000 04:22:44 -0000
Received: from unknown (HELO em) (203.161.252.186) by asiainter.net with SMTP; 30 Nov 2000 04:22:44 -0000
Message-ID: <008701c05a85$245f00d0$6000a8c0@em>
From: "Enzo Michelangeli" <[e-mail]>
To: "Bob Jueneman" <[e-mail]>, "Bonatti, Chris" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: RSA vs. DSA MUST
Date: Thu, 30 Nov 2000 11:59:47 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----- Original Message -----
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Sent: Thursday, November 30, 2000 7:18 AM
Subject: Re: RSA vs. DSA MUST

[...]
> As a result, Product Management is increasingly inclined to
> "Just Say NO" to these kinds of features, which ends up making
> IETF standards increasingly irrelevant and making interoperability
> that much harder, rather than easier.

I think that Product Management needs to understand that in the Internet age
interoperability is, for a vendor, matter of life and death; I think your
company grasps this point well, as it bit the bullet several years ago by
embracing TCP/IP.

> The real challenge in creating standards is therefore not to
> attempt to see how many you can create with all of their rococo
> variations, but rather how few you can get by with and still
> get the job done.  To the extent that the IETF WGs become
> self-justifying, self-perpetuating, and eternal, the less useful
> they become, IMHO.  We are becoming more and more like ISO every
> day, and maybe worse.

Gee Bob, you stole my line: I was planning to title one of my postings "The
X.400-ization of secure e-mail". Does everyboy remember X.400 (1984) and
X.400 (1988)? Both S/MIME and OpenPGP, at this moment, exist in two major
versions that do not necessarily interoperate with each other, and for the
same damn reason (old intellectual property issues on cryptographic
algorithms, now in large part disappeared).

> This is really a case of Little Red Riding Hood's porridge.
> We want it to be not too hot (needlessly feature rich), and
> not too cold (missing important capabilities or security,
> forcing everyone to devolve to the lowest common denominator),
> but rather just right.  And that requires making intelligent CHOICES.

Here is my modest proposal for SMIME v.3 sole MUST requirements:

- Full interoperability with SMIME v.2, therefore #include-ing all the MUST
of RFC2311;
- Minimum key length raised to 1024-bit for PK and 112-bit for symmetric
algorithms;
- At least one other key exchange algorithm and one signature algorithm
unrelated to the problem of modular factorization, to protect against
possible unpleasant effects of progress in numbers theory. I'd say that DSA
and DH are the best candidates, if we want to exorcise the IP curse that
could strike ECC-based techniques;
- 3DES-EDE and Rijndael added to RC2.

Cheers --

Enzo





Received: by ns.secondary.com (8.9.3/8.9.3) id TAA24387 for ietf-smime-bks; Wed, 29 Nov 2000 19:00:04 -0800 (PST)
Received: from mailhost3.lanl.gov (mailhost3.lanl.gov [128.165.3.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA24383 for <[e-mail]>; Wed, 29 Nov 2000 19:00:02 -0800 (PST)
Received: (from root@localhost) by mailhost3.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) id eAU2vRJ12068; Wed, 29 Nov 2000 19:57:27 -0700
Received: from mailproxy.lanl.gov ([128.165.254.25]) by mailhost3.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMVG419269; Wed, 29 Nov 2000 15:31:17 -0700
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by mailproxy.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMVEf31198; Wed, 29 Nov 2000 15:31:14 -0700
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id RAA06575 for [e-mail]; Wed, 29 Nov 2000 17:15:01 -0500 (EST)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA01543 for <[e-mail]>; Wed, 29 Nov 2000 06:31:42 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02101; Wed, 29 Nov 2000 06:31:41 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-x400wrap-01.txt
Date: Wed, 29 Nov 2000 06:31:41 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Securing X.400 Content with S/MIME
	Author(s)	: P. Hoffman, C. Bonatti
	Filename	: draft-ietf-smime-x400wrap-01.txt
	Pages		: 
	Date		: 28-Nov-00
	
This document describes a protocol for adding cryptographic signature
and encryption services to X.400 content.

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--





Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA24375 for ietf-smime-bks; Wed, 29 Nov 2000 18:59:37 -0800 (PST)
Received: from mailman.lanl.gov (mailman.lanl.gov [128.165.5.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA24370 for <[e-mail]>; Wed, 29 Nov 2000 18:59:35 -0800 (PST)
Received: (from root@localhost) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) id eAU2gAQ16496; Wed, 29 Nov 2000 19:42:10 -0700
Received: from mailproxy.lanl.gov ([128.165.254.25]) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMMZf26535; Wed, 29 Nov 2000 15:22:35 -0700
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by mailproxy.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMMXf29458; Wed, 29 Nov 2000 15:22:33 -0700
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id RAA06503 for [e-mail]; Wed, 29 Nov 2000 17:05:01 -0500 (EST)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA01536 for <[e-mail]>; Wed, 29 Nov 2000 06:31:38 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02047; Wed, 29 Nov 2000 06:31:37 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-examples-05.txt
Date: Wed, 29 Nov 2000 06:31:36 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Examples of S/MIME Messages
	Author(s)	: P. Hoffman
	Filename	: draft-ietf-smime-examples-05.txt
	Pages		: 8
	Date		: 28-Nov-00
	
This document gives examples of message bodies formatted using S/MIME.
Specifically, it has examples of Cryptographic Message Syntax (CMS)
objects, S/MIME messages (including the MIME formatting), and Enhanced
Security Services for S/MIME (ESS). It includes examples of most or all
common CMS and ESS formats; in addition, it gives examples that show
common pitfalls in implementing CMS. The purpose of this document is to
help increase interoperability for S/MIME and other protocols that rely
on CMS.
This draft is being discussed on the 'ietf-smime' mailing list.  To
join the list, send a message to <[e-mail]> with the
single word 'subscribe' in the body of the message.  Also, there is a
Web site for the mailing list at <http://www.imc.org/ietf-smime/>.

This draft is being discussed on the 'ietf-smime' mailing list.  To
join the list, send a message to <[e-mail]> with the
single word 'subscribe' in the body of the message.  Also, there is a
Web site for the mailing list at <http://www.imc.org/ietf-smime/>.

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-examples-05.txt

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

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

--OtherAccess--

--NextPart--





Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA24368 for ietf-smime-bks; Wed, 29 Nov 2000 18:59:29 -0800 (PST)
Received: from mailman.lanl.gov (mailman.lanl.gov [128.165.5.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA24364 for <[e-mail]>; Wed, 29 Nov 2000 18:59:28 -0800 (PST)
Received: (from root@localhost) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) id eAU2dG814653; Wed, 29 Nov 2000 19:39:16 -0700
Received: from mailproxy.lanl.gov ([128.165.254.25]) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMEgf24308; Wed, 29 Nov 2000 15:14:42 -0700
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by mailproxy.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMEff28052; Wed, 29 Nov 2000 15:14:41 -0700
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id QAA06414 for [e-mail]; Wed, 29 Nov 2000 16:55:01 -0500 (EST)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA01529 for <[e-mail]>; Wed, 29 Nov 2000 06:31:32 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02003; Wed, 29 Nov 2000 06:31:31 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-compression-03.txt
Date: Wed, 29 Nov 2000 06:31:31 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Compressed Data Content Type for S/MIME
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-smime-compression-03.txt
	Pages		: 
	Date		: 28-Nov-00
	
The Cryptographic Message Syntax data format doesn't currently contain
any provisions for compressing data before processing it. Compressing
data before transmission provides a number of advantages including the
elimination of data redundancy which could help an attacker, speeding
up processing by reducing the amount of data to be processed by later
steps such as signing or encryption, and reducing overall message
size. Although there have been proposals for adding compression at
other levels (for example at the MIME or SSL level) these don't
address the problem of compression of CMS content unless the
compression is supplied by an external means (for example by
intermixing MIME and CMS).  This document defines a format for using
compressed data as a CMS content type.

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-compression-03.txt

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

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

--OtherAccess--

--NextPart--





Received: by ns.secondary.com (8.9.3/8.9.3) id SAA23994 for ietf-smime-bks; Wed, 29 Nov 2000 18:37:01 -0800 (PST)
Received: from mailman.lanl.gov (mailman.lanl.gov [128.165.5.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA23990 for <[e-mail]>; Wed, 29 Nov 2000 18:36:59 -0800 (PST)
Received: (from root@localhost) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) id eAU2cXb13973; Wed, 29 Nov 2000 19:38:33 -0700
Received: from mailproxy.lanl.gov ([128.165.254.25]) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMDVf23697 for <[e-mail]>; Wed, 29 Nov 2000 15:13:31 -0700
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by mailproxy.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMDUf27814 for <[e-mail]>; Wed, 29 Nov 2000 15:13:30 -0700
Received: by ns.secondary.com (8.9.3/8.9.3) id NAA14577 for ietf-smime-bks; Wed, 29 Nov 2000 13:57:34 -0800 (PST)
Received: from smtp-a.capu.net (IDENT:[e-mail] [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA14573 for <[e-mail]>; Wed, 29 Nov 2000 13:57:32 -0800 (PST)
Received: from ieca.com (mva-aa-086.capu.net [207.226.159.86]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id QAA24513 for <[e-mail]>; Wed, 29 Nov 2000 16:59:04 -0500
Message-ID: <[e-mail]>
Date: Wed, 29 Nov 2000 16:58:58 -0500
From: "Bonatti, Chris" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: RSA vs. DSA MUST
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA22983 for ietf-smime-bks; Wed, 29 Nov 2000 18:06:18 -0800 (PST)
Received: from mailman.lanl.gov (mailman.lanl.gov [128.165.5.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA22964 for <[e-mail]>; Wed, 29 Nov 2000 18:06:11 -0800 (PST)
Received: (from root@localhost) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) id eAU20xk30850; Wed, 29 Nov 2000 19:00:59 -0700
Received: from mailproxy.lanl.gov ([128.165.254.25]) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMMZf26535; Wed, 29 Nov 2000 15:22:35 -0700
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by mailproxy.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMMXf29458; Wed, 29 Nov 2000 15:22:33 -0700
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id RAA06503 for [e-mail]; Wed, 29 Nov 2000 17:05:01 -0500 (EST)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA01536 for <[e-mail]>; Wed, 29 Nov 2000 06:31:38 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02047; Wed, 29 Nov 2000 06:31:37 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-examples-05.txt
Date: Wed, 29 Nov 2000 06:31:36 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Examples of S/MIME Messages
	Author(s)	: P. Hoffman
	Filename	: draft-ietf-smime-examples-05.txt
	Pages		: 8
	Date		: 28-Nov-00
	
This document gives examples of message bodies formatted using S/MIME.
Specifically, it has examples of Cryptographic Message Syntax (CMS)
objects, S/MIME messages (including the MIME formatting), and Enhanced
Security Services for S/MIME (ESS). It includes examples of most or all
common CMS and ESS formats; in addition, it gives examples that show
common pitfalls in implementing CMS. The purpose of this document is to
help increase interoperability for S/MIME and other protocols that rely
on CMS.
This draft is being discussed on the 'ietf-smime' mailing list.  To
join the list, send a message to <[e-mail]> with the
single word 'subscribe' in the body of the message.  Also, there is a
Web site for the mailing list at <http://www.imc.org/ietf-smime/>.

This draft is being discussed on the 'ietf-smime' mailing list.  To
join the list, send a message to <[e-mail]> with the
single word 'subscribe' in the body of the message.  Also, there is a
Web site for the mailing list at <http://www.imc.org/ietf-smime/>.

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-examples-05.txt

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

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

--OtherAccess--

--NextPart--





Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA22972 for ietf-smime-bks; Wed, 29 Nov 2000 18:06:13 -0800 (PST)
Received: from mailman.lanl.gov (mailman.lanl.gov [128.165.5.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA22961 for <[e-mail]>; Wed, 29 Nov 2000 18:06:11 -0800 (PST)
Received: (from root@localhost) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) id eAU20XQ29644; Wed, 29 Nov 2000 19:00:33 -0700
Received: from mailproxy.lanl.gov ([128.165.254.25]) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMEgf24308; Wed, 29 Nov 2000 15:14:42 -0700
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by mailproxy.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMEff28052; Wed, 29 Nov 2000 15:14:41 -0700
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id QAA06414 for [e-mail]; Wed, 29 Nov 2000 16:55:01 -0500 (EST)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA01529 for <[e-mail]>; Wed, 29 Nov 2000 06:31:32 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02003; Wed, 29 Nov 2000 06:31:31 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-compression-03.txt
Date: Wed, 29 Nov 2000 06:31:31 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Compressed Data Content Type for S/MIME
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-smime-compression-03.txt
	Pages		: 
	Date		: 28-Nov-00
	
The Cryptographic Message Syntax data format doesn't currently contain
any provisions for compressing data before processing it. Compressing
data before transmission provides a number of advantages including the
elimination of data redundancy which could help an attacker, speeding
up processing by reducing the amount of data to be processed by later
steps such as signing or encryption, and reducing overall message
size. Although there have been proposals for adding compression at
other levels (for example at the MIME or SSL level) these don't
address the problem of compression of CMS content unless the
compression is supplied by an external means (for example by
intermixing MIME and CMS).  This document defines a format for using
compressed data as a CMS content type.

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-compression-03.txt

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

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

--OtherAccess--

--NextPart--





Received: by ns.secondary.com (8.9.3/8.9.3) id RAA22779 for ietf-smime-bks; Wed, 29 Nov 2000 17:58:55 -0800 (PST)
Received: from mailman.lanl.gov (mailman.lanl.gov [128.165.5.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA22775 for <[e-mail]>; Wed, 29 Nov 2000 17:58:54 -0800 (PST)
Received: (from root@localhost) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) id eAU20R429348; Wed, 29 Nov 2000 19:00:27 -0700
Received: from mailproxy.lanl.gov ([128.165.254.25]) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMDVf23697 for <[e-mail]>; Wed, 29 Nov 2000 15:13:31 -0700
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by mailproxy.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMDUf27814 for <[e-mail]>; Wed, 29 Nov 2000 15:13:30 -0700
Received: by ns.secondary.com (8.9.3/8.9.3) id NAA14577 for ietf-smime-bks; Wed, 29 Nov 2000 13:57:34 -0800 (PST)
Received: from smtp-a.capu.net (IDENT:[e-mail] [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA14573 for <[e-mail]>; Wed, 29 Nov 2000 13:57:32 -0800 (PST)
Received: from ieca.com (mva-aa-086.capu.net [207.226.159.86]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id QAA24513 for <[e-mail]>; Wed, 29 Nov 2000 16:59:04 -0500
Message-ID: <[e-mail]>
Date: Wed, 29 Nov 2000 16:58:58 -0500
From: "Bonatti, Chris" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: RSA vs. DSA MUST
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA21745 for ietf-smime-bks; Wed, 29 Nov 2000 17:19:36 -0800 (PST)
Received: from bbs.ht.net.cn ([202.103.160.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA21740 for <[e-mail]>; Wed, 29 Nov 2000 17:19:34 -0800 (PST)
From: [e-mail]
Received: from h809 (1Cust82.tnt1.mia5.da.uu.net [63.30.194.82]) by bbs.ht.net.cn (8.8.7/8.7.3) with SMTP id JAA15367; Thu, 30 Nov 2000 09:38:25 +0800
Date: Thu, 30 Nov 2000 09:38:25 +0800
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Lady V:  The Pleasure Pill for Women!
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

LADY V: The Pleasure Pill for Women!

Men Have Their Viagra®! Finally, A Pill for Women! 

It's Here! The Revolutionary Woman's Sexual Sensation is Now
                           Available.

Researchers are calling Lady V the greatest breakthrough
for women since the Birth Control Pill. And you don't even need
a prescription to get it!

               Welcome to the New Sexual Revolution!

It's no secret that men have been having the time of their
lives since the wonder pill Viagra® was made available. But,
women were left out in the cold with no pill... nothing! 
Well now thanks to an all-star team of medical researchers 
who have been working around the clock, those days are finally
over. The perfect female "pleasure pill" has been created and
you don't even need a prescription. You can now get it from
Lion Sciences!

Lady V is the world's first pleasure pill scientifically 
designed for women. Lady V is an all-natural proprietary 
herbal blend of prosexual nutrients from around the world
synergistically blended to naturally stimulate neurotransmitter
endorphin signals. This magical combination increases targeted
blood flow, unleashes natural stimulator for maximum stimulation,
triggering pleasure responses quickly. Lady V is safe, natural
and doctor-recommended.
Since its introduction Lady V has been taking the world by storm!
>From Malibu to Miami women are enjoying the most intense pleasure
of their lives! 

• 100% Natural
• Safe
• The Highest Quality Pharmaceutical Pure Nutraceuticals
• Guaranteed Potency
• Certified Purity

                     Lady V is Sweeping the Nation!

Women are going crazy over Lady V. Suddenly couples are falling
in love all over again. The passion and pleasure that women are
reporting is off the charts! Lady V has an incredible 88% success
rate. Best of all, while Viagra costs $10 a pill, Lady V costs
less than $1 a pill! It's not just a man's world anymore!

Just look at what a few women have to say:

"I thought my love life was good before, but now it is out of
this world! Lady V is remarkable." — Mary J., Interior Designer

"I haven't smiled like this in a long time. My husband and I 
feel like a couple of 19 year olds again!" — Debra T, Assistant Buyer

"Imagine what it would feel like to have incredible passion
and pleasure anytime you want." — Jennifer C., Film Editor

"Suddenly my husband and I are spending more time in the bedroom
instead of the TV room." — Angie R., Realtor

Ingredients: Vitamin D, Niacin, Vitamin B6, Folic Acid,
Vitamin B12, Avena Sativa, Kava Kava, Guarana, White Willow Extract,
Mura Puama, St. John's Wort, Siberian Ginseng, Cordyceps, Damiana,
and L-Taurine.

Each bottle of Lady V contains 30 tablets.
Take three capsules one hour before romantic activity
as a dietary supplement. 

Risk Free: Double Your Money Back Guarantee

If Lady V does not give the desired results as stated
above, simply return the unused portion for a
double-your money back refund. No questions asked! 

Order Now: Safe, Fast, Secure, Private

Lady V with its DOUBLE YOUR MONEY BACK GUARANTEE is
available only through this special promotional offer.
Herbal V arrives in plain packaging for your privacy.
Any and all information is kept strictly confidential.

Payment Methods

You may FAX or Postal Mail Checks, MasterCard, Visa,
& American Express.payments. Money Orders
are accepted only by Postal Mail. 


Each bottle of Lady V contains 30 tablets.


Step 1: Place a check by your desired quanity.


______ 1 Bottle of Lady V  $24


______ 2 Bottles of Lady V $44


______ 3 Bottles of Lady V $59


Please add $6 shipping and handling for any size order. 
[ Total cost including shipping & handling, 
1 bottle=$30, 2 bottles=$50, 3 bottles=$65 ]

International Orders
Please add $18 shipping and handling for any size order.
[ Total cost including shipping & handling,
1 bottle=$42, 2 bottles=$62, 3 bottles=$77 ]
We cannot accept foreign checks.
International money orders or credit cards only.

Step 2: Place a check by your desired payment method 
and complete fields if necessary.


_____Check or CHECK-BY-FAX [details below]


_____Money Order 


_____American Express 
Account Number__________________ Exp____/____

_____Visa
Account Number__________________ Exp____/____

_____MasterCard
Account Number__________________ Exp____/____


Please make your check or money order payable to
"Lion Sciences National".
 

Step 3: Please complete and print the following fields clearly.


Name ___________________________________________________ 


Address _________________________________________________


City ____________________________________________________ 


State ___________________________________________________ 


Zip _____________________________________________________ 


E-mail __________________________________________________ 


Signature _________________________________________________
[ required for check and credit card orders]



             Toll Free FAX Order Line: 1-800-940-6590
If faxing in your order, please state whether you require
a fax, email, or no confirmation at all. 
Allow up to one day for confirmation, if requested.
FAX orders are processed immediately.

  Or, print & mail to: LSN   
                       273 S. State Rd. 7, #193
                       Margate, FL 33068-5727               


        ______________________________________________________


*CHECK BY FAX ORDERS: Complete the check as normal. Tape
the check in the area below. Below the check, clearly write
the check number, all numbers at the bottom of the check,
& your name. Tape the check below and fax the check to the
toll free FAX number above. Void the check. Our merchant
will electronically debit your account for the amount of 
the check; your reference number for this transaction will
be your check number. Nothing could be safer & easier !

                          TAPE CHECK BELOW















              _____________________________________________________________

This is a one time mailing: Removal is automatic and no further 
contact is necessary. Please Note: Lady V is not intended to
diagnose, treat, cure or prevent any disease. As individuals differ,
so will results. Lady V helps provide herbal and nutritional support
for female sexual performance. The FDA has not evaluated these 
statements. For details about our double your money back guarantee,
please write to the above address, attention consumer affairs 
department; enclose a self addressed stamped envelope for this and any 
requested contact information.
Thank You.



Received: by ns.secondary.com (8.9.3/8.9.3) id QAA20241 for ietf-smime-bks; Wed, 29 Nov 2000 16:16:36 -0800 (PST)
Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA20237 for <[e-mail]>; Wed, 29 Nov 2000 16:16:35 -0800 (PST)
Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=celocom.com) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 141HQM-0000ko-0A for [e-mail]; Thu, 30 Nov 2000 00:18:07 +0000
Message-ID: <[e-mail]>
Date: Thu, 30 Nov 2000 00:17:46 +0000
From: Dr S N Henson <[e-mail]>
Organization: S N Henson
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: RSA vs. DSA MUST
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Bonatti, Chris" wrote:
> 
>     Reading through this thread, I am astonished at a couple of apparent truisms that are emerging from the various earnest statements made.  These are (employing a little editorial license):
> 
>    * The implementation cost of DSA/D-H/3DES was acceptable when RSA was patented, but now that some of us have actually built/tested this the cost has gone up into the "too high" range.
> 

I'd say in the DH case (and to some extent DSA) there's the issue of how
practical it is. The only DH certificates I've ever seen were in the
S/MIME examples draft. I suspect there are problems with the parameters
but despite repeated queries I never found anyone who could
independently check them.

If public CAs issuing DSA certificates are rare then I'd say CAs issuing
DH certificates are virtually non existent. Does anyone know of a single
example?

Its all very nice adding support for DSA and DH but if users can't get
any certificates from public CAs then their value is severely limited.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [e-mail] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [e-mail] PGP key: via homepage.



Received: by ns.secondary.com (8.9.3/8.9.3) id QAA19961 for ietf-smime-bks; Wed, 29 Nov 2000 16:03:59 -0800 (PST)
Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA19956 for <[e-mail]>; Wed, 29 Nov 2000 16:03:58 -0800 (PST)
Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 011686078; Wed, 29 Nov 2000 19:05:31 -0500 (EST)
Received: from caveosystems.com (adsl-141-154-13-230.bellatlantic.net [141.154.13.230]) by os390.caveosystems.com (8.9.3/8.9.3) with ESMTP id TAA15777; Wed, 29 Nov 2000 19:06:06 -0500
Message-ID: <[e-mail]>
Date: Wed, 29 Nov 2000 19:08:41 -0500
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Bonatti, Chris" <[e-mail]>
CC: [e-mail]
Subject: Re: RSA vs. DSA MUST
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think your perception is slightly (but significantly) off.

Some folks implemented DSA-family, but most folks paid money and licensed RSA
and did that.  Apparently some of those DSA implementors would rather not bear
the continued cost of maintaining a code branch that has seen no customer
demand.  That's a high cost just to be able to claim IETF SMIME compliance.

To be algorithm independant, you make sure you always identify the algorithm,
and don't mistakenly say "encrypted data" without specifying the mechanism. 
During development of the standards, a good way to do that is to make sure
multiple mechanisms are specified. In this case, the theoretical (DSA) and the
practical (RSA).

Peter Gutman said it best a few weeks ago, shortly after RSA expired. 
Something along the lines of "we all pretended to do DSA, but in reality
everyone did RSA."  For political reasons, the IETF bent over backwards to
avoid mandating patented technology.

>Personally, I favor products that support LOTS of interoperability modes.

That's nonsensical.  Do you prefer BER over DER? :)

The marketplace has decided and the common crypto mechanism is RSA, and
practically nobody cares about DSA.  Certainly, making DSA not MUST will not
hurt the DSA-using community.

It's not the IETF's job to raise the bar.  It's the IETF's job to make sure we
all speak the same language, and clearly that language is mod-exp.
	/r$


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA17335 for ietf-smime-bks; Wed, 29 Nov 2000 15:18:15 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA17331 for <[e-mail]>; Wed, 29 Nov 2000 15:18:14 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 29 Nov 2000 16:18:46 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Wed, 29 Nov 2000 16:18:47 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: RSA vs. DSA MUST
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA17332
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chris, I believe these points are important, and perhaps more important than the particular issues at hand.  So please allow me to wax philosophical.

As a consumer, all things being equal, I like products that support lots of interoperability modes too.  Beer, champagne, hot dogs, filet mignon, ice cream, apple pie, floor wax and desert topping -- they're all great, at least if you can afford them.

But as a vendor, I am increasingly concerned about the amount of feature creep that we are seeing every day in both the PKIX and SMIME groups, apparently  almost unconstrained by business requirements.  We need interoperability, and that should not mean lowest common denominator, but it also shouldn't mean being all things to all men.

Although the development cost of adding a particular feature tends to go up linearly, the testing and interoperability costs tend to go up with the SQUARE of the features, all of which generally have to be tested in all possible combinations.  That is both expensive and time consuming, and leads to products that are either buggy or late, or typically both.  And that clearly doesn't benefit the consumer at all.

As a result, Product Management is increasingly inclined to "Just Say NO" to these kinds of features, which ends up making IETF standards increasingly irrelevant and making interoperability that much harder, rather than easier.

The real challenge in creating standards is therefore not to attempt to see how many you can create with all of their rococo variations, but rather how few you can get by with and still get the job done.  To the extent that the IETF WGs become self-justifying, self-perpetuating, and eternal, the less useful they become, IMHO.  We are becoming more and more like ISO every day, and maybe worse.

Now allow me to (gently, I hope) take issue with some of your other statements:
>
>>>> "Bonatti, Chris" <[e-mail]> 11/29/00 02:58PM >>>
>    Reading through this thread, I am astonished at a couple of apparent truisms that are emerging from the various earnest statements made.  These are 
>(employing a little editorial license):
>
>   * The implementation cost of DSA/D-H/3DES was acceptable when RSA was patented, but now that some of us have actually built/tested this the cost 
>has gone up into the "too high" range.

I would disagree.  The cost of the RSA license was minimal relative to other development costs, and the RSA algorithm was effectively all there was in terms of deployed PKI infrastructure.  The fact that DSA and D-H were labeled MUST was chalked up to IETF politics, and completely ignored by the vendor community as not being worth the implementation cost in terms of revenue return. Granted, it didn't meet some of the expressed desires of the US Government, but the USG has always had a much bigger appetite than budget.  (Remember Jovial?  Ada?  C2 by '92?)  Money talks, and everything else walks.  They imposed requirements, but those requirements didn't stick when it came to real procurements.
>
>   * Specifying a single MUST algorithm suite was sufficient to make S/MIME algorithm independent, but actually requiring two algorithms suites will cost too 
>much.  If we've really achieved algorithm independence in the sense that Dave Kemp suggests, this should be a debate about a relatively small math module.

No, again I disagree.  The math module isn't the problem.  As a BSAFE licensee, we already have all of the math modules we would need.  The real issue is all of the multitudinous GUI screens that have to be developed to allow the user to choose this, that or the other algorithm within S/MIME, and then the same set of choices in any PKI products, and then testing all of these options in every conceivable combination, not just within a given product but in combination with all of the other leading e-mail packages, plus the various PKI services and toolkits as well.  those costs dwarf the cost of the math module by a couple of orders of magnitude.

>   * We have an 'SMIMECapabilities' attribute for which support is MUST, but some implementations ignore it so we have to use the lowest common 
>denominator to force interoperability.  What make anybody think a MUST on an algorithm choice would be taken any more seriously?

Two issues.  As I recall, the SMIMECapabilities is a MAY, not a MUST, although I'll stand corrected if I'm wrong.  And as I say, and Peter Gutmann said more succinctly, MUST matters if and only if the vendor was inclined to implement that option anyway.  It might be sufficient to push someone over the fence who was already 49% there, but not much more.  Standards compliance doesn't pay the rent -- customers do.
>
>    I don't think I actually have an opinion on this issue myself.  I'm of the mind set to mandate nothing and let Darwin decide.  However, I find the seeming 
>illogic of these collective opinions very troubling.  It leads me to think that we're not getting to the REAL reasoning behind this move.
>
>    I think Blake was closest to this in stating that there has been no customer demand for DSA.  Is this the REAL reason to dump DSA?  Are customers 
>demanding RSA be used?  Do customers express demand for any algorithms, or do they just want it to be "secure"?  Are we just drifting to the path of least 
>resistance?

Customers don't demand or specify algorithms.  They just want it to be secure, and trust that the vendor will figure out what that means.  What they do insist on, however, is that the product work well with the existing infrastructure in order to reduce their total overall cost of ownership.  The more sophisticated customers realize that adding more and more features that they never use significantly increases that TCO, so overburdening a product with unnecessary features causes a significant backlash.  Increased cost of development with decreased sales.  What a concept!
>
>    Personally, I favor products that support LOTS of interoperability modes... not just lowest common denominators.  Call me crazy, but...
>
>Chris B.

This is really a case of Little Red Riding Hood's porridge.  We want it to be not too hot (needlessly feature rich), and not too cold (missing important capabilities or security, forcing everyone to devolve to the lowest common denominator), but rather just right.  And that requires making intelligent CHOICES.

I like mustard, and I like chocolate.  But that doesn't mean that I want chocolate on my hot dog, nor mustard on my ice cream, just because I have them both in my refrigerator. :-)

Regards,

Bob



Received: by ns.secondary.com (8.9.3/8.9.3) id PAA16860 for ietf-smime-bks; Wed, 29 Nov 2000 15:13:32 -0800 (PST)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16856 for <[e-mail]>; Wed, 29 Nov 2000 15:13:32 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com (dial04.spyrus.com [207.212.34.124]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id PAA01758; Wed, 29 Nov 2000 15:13:26 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 29 Nov 2000 18:00:44 -0500
To: [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: IESG ACTION NEEDED: draft-ietf-smime-compression-03.txt
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeff & Marcus:

The S/MIME WG has finished work on the CMS compressed data type.  This 
Interned-Draft is ready for IETF Last Call and approval by the IESG as a 
standards-track RFC.

	Title		: Compressed Data Content Type for S/MIME
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-smime-compression-03.txt
	Date		: 28-Nov-00
	
RFC 2630 (CMS) doesn't currently contain any provisions for compressing 
data before processing it. Compressing data before transmission provides a 
number of advantages including the elimination of data redundancy which 
could help an attacker, speeding
up processing by reducing the amount of data to be processed by later steps 
such as signing or encryption, and reducing overall message size. Although 
there have been proposals for adding compression at other levels (for 
example at the MIME or SSL level) these don't address the problem of 
compression of CMS content unless the
compression is supplied by an external means (for example by intermixing 
MIME and CMS).  This document defines a format for using compressed data as 
a CMS content type.

Russ



Received: by ns.secondary.com (8.9.3/8.9.3) id NAA14577 for ietf-smime-bks; Wed, 29 Nov 2000 13:57:34 -0800 (PST)
Received: from smtp-a.capu.net (IDENT:[e-mail] [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA14573 for <[e-mail]>; Wed, 29 Nov 2000 13:57:32 -0800 (PST)
Received: from ieca.com (mva-aa-086.capu.net [207.226.159.86]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id QAA24513 for <[e-mail]>; Wed, 29 Nov 2000 16:59:04 -0500
Message-ID: <[e-mail]>
Date: Wed, 29 Nov 2000 16:58:58 -0500
From: "Bonatti, Chris" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: RSA vs. DSA MUST
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

    Reading through this thread, I am astonished at a couple of apparent truisms that are emerging from the various earnest statements made.  These are (employing a little editorial license):

   * The implementation cost of DSA/D-H/3DES was acceptable when RSA was patented, but now that some of us have actually built/tested this the cost has gone up into the "too high" range.

   * Specifying a single MUST algorithm suite was sufficient to make S/MIME algorithm independent, but actually requiring two algorithms suites will cost too much.  If we've really achieved algorithm independence in the sense that Dave Kemp suggests, this should be a debate about a relatively small math module.

   * We have an 'SMIMECapabilities' attribute for which support is MUST, but some implementations ignore it so we have to use the lowest common denominator to force interoperability.  What make anybody think a MUST on an algorithm choice would be taken any more seriously?

    I don't think I actually have an opinion on this issue myself.  I'm of the mindset to mandate nothing and let Darwin decide.  However, I find the seeming illogic of these collective opinions very troubling.  It leads me to think that we're not getting to the REAL reasoning behind this move.

    I think Blake was closest to this in stating that there has been no customer demand for DSA.  Is this the REAL reason to dump DSA?  Are customers demanding RSA be used?  Do customers express demand for any algorithms, or do they just want it to be "secure"?  Are we just drifting to the path of least resistance?

    Personally, I favor products that support LOTS of interoperability modes... not just lowest common denominators.  Call me crazy, but...

Chris B.






Received: by ns.secondary.com (8.9.3/8.9.3) id MAA08769 for ietf-smime-bks; Wed, 29 Nov 2000 12:20:48 -0800 (PST)
Received: from smtp01.infoave.net (smtp01.infoave.net [165.166.0.26]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08756 for <[e-mail]>; Wed, 29 Nov 2000 12:20:46 -0800 (PST)
Received: from linus.corecom.com ([64.53.5.179]) by SMTP00.InfoAve.Net (PMDF V5.2-33 #45321) with ESMTP id <[e-mail]> for [e-mail]; Wed, 29 Nov 2000 15:22:16 EDT
Date: Wed, 29 Nov 2000 15:23:27 -0500
From: Dave Piscitello <[e-mail]>
Subject: TISC 2001 Call for Papers, Session Abstracts
X-Sender: [e-mail]@mail2.netreach.net
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Content-type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

The Fifth Internet Security Conference will be held June 4-8,
2001 at the Century Plaza Hotel and Tower, 2025 Avenue of the
Stars, Century City Los Angeles, CA 90067-4696. TISC is an
educational forum for security professionals and practitioners.
The TISC Security Symposium is an opportunity for individuals
to share their expertise and practical experience with others
involved in the design, implementation and deployment of
networked security systems.

We cordially invite you to submit an abstract for an original
paper. Accepted papers will be presented at the conference.
We also invite you to submit a session abstract for
consideration, or if you prefer, to present a topic as a
panel member. We encourage you to submit abstracts and topics
by December 8. Further information can be found at
http://tisc.corecom.com. Or send your proposal to me
at mailto:[e-mail].

We look forward to your participation. Thank you.

Warm Regards,

Dave Piscitello
On behalf of the TISC Advisory Board


                            David M. Piscitello
             Core Competence, Inc. (http://www.corecom.com) and
      The Internet Security Conference (http://tisc.corecom.com)
     ~~ The Internet has security problems. We have answers. ~~

3 Myrtle Bank Lane                                     [e-mail]
Hilton Head, SC 29926                                  1.843.683-9988

PGP Fingerprint: 070A 9F01 C35C 4D41 A460 EF2C 2992 2F12 11D2 02DC



Received: by ns.secondary.com (8.9.3/8.9.3) id KAA00138 for ietf-smime-bks; Wed, 29 Nov 2000 10:09:35 -0800 (PST)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA00132 for <[e-mail]>; Wed, 29 Nov 2000 10:09:34 -0800 (PST)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.6)); Wed, 29 Nov 2000 10:10:34 -0800
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2650.21) id <XJ563ZCK>; Wed, 29 Nov 2000 10:10:34 -0800
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: RE: RSA vs. DSA MUST
Date: Wed, 29 Nov 2000 10:10:34 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 163B991038585-01-01
Content-Type: text/plain;  charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

An inimitable Gutmannism.

This could also be summarized as Paul did it when we first started this
discussion back in July:

> Blake Ramsdell has turned in two drafts that are worthy of 
> consideration in this group. It's my opinion that they represent the 
> reality of the marketplace, and that it would be good to have our 
> RFCs reflect that if possible.

Which was exactly my intent.  There seems to be some disconnect between the
current discussion and the strawpoll consensus at the last IETF, which needs
to be resolved, however.

I would certainly welcome how I should interpret "BWAHAHAHAHAHA" in the
context of MUST and SHOULD, however.

Blake

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, November 29, 2000 6:44 AM
To: [e-mail]; [e-mail]; [e-mail]
Subject: Re: RSA vs. DSA MUST


"Bob Jueneman" <[e-mail]> writes:

>I'm not necessarily advocating this position -- I might like to think about
it
>some more myself -- but just for the sake of argument and to take the
pulse,
>what would people think of making ANSI X9.31 RSA a MUST,  X9.31 EC-DSA a
>SHOULD, and DSA and PKCS-1 RSA a MAY?

How about trying to make the spec at least vaguely approximate reality in
the
choice of algorithms?  It doesn't really matter if you include requirements
like "MUST DSA OR WE WILL KILL YOU[0], SHOULD NOT RSA", in practice the
world
will interpret it as "MUST RSA, MAY DSA, SHOULD NOT X9.42 DH, BWAHAHAHAHAHA
X9.31 RSA" no matter what it says in the RFC (I think IBM does X9.31 in CCA
but
does anything else in existence implement this?).  

I've been sitting here watching this debate go on and on, but since no
matter
what you put in the RFC the market will interpret it as MUST RSA and various
levels of deprecation for anything else maybe we could get Markov Chaney to
continue the debate for a while just for forms sake and then after enough
messages have been exchanged to satisfy everyone either put text in the RFC
which accepts what everyone's going to do anyway or which specifies all
sorts
of options and alternatives secure in the knowledge that implementors will
ignore it and do what the market wants/expects, which ain't DSA or X9.31
RSA.

Peter.

[0] RFC 2026bis, "When MUST just isn't enough".





Received: by ns.secondary.com (8.9.3/8.9.3) id IAA25376 for ietf-smime-bks; Wed, 29 Nov 2000 08:57:25 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA25371 for <[e-mail]>; Wed, 29 Nov 2000 08:57:24 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 29 Nov 2000 09:58:16 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Wed, 29 Nov 2000 09:58:15 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: SMIMECapabilites for AES, etc.
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA25372
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>> Although it isn't strictly interactive in the sense that SSL is,
>> the SMIMECapabilities attribute allows the originator of a message
>> to indicate his preference as to encryption algorithms, including
>> 40-bit RC4 vs. 56-bit DES > vs. 128-bit whatever vs. 196-bit
>> triple-DES (and soon, presumably, 256-bit AES).
>
>Yes, but on the open Internet most certificates are sent as part of the
>message (presently in PKCS#7 format), not retrieved from global directories
>as the X.500 folks initially hoped. In that context, the recipient would
>have to send an initial signed message to the sender to indicate the user
>agent's capabilities: and in most cases (like one I mentioned of the mailing
>list) that's just not viable.
>
>Enzo
>
>
You are correct, of course.  I was thinking  about the encryption case, primarily, where it is much more likely that the recipients would have exchanged at least a signed message, precisely in order to exchange certificates.

That does bring up a good point regarding AES, however.  In the past, it was usually possible to make a good guess as to whether to use a 40-bit key (RC2 or RC4) or a full strength key (DES, triple-DES, or perhaps 128-bit RC2 or RC4) based on what you knew about the recipient, in particular whether he or she was in the US or Canada, or somewhere else that was more likely to be subject to export controls.  And nearly all of the e-mail packages implemented RC2 and RC4, and the "domestic-strength" packages implemented both DES and triple-DES. So the SMIMECapabilities attribute wasn't really all that necessary.

As we begin the transition to AES, however, that won't be the case.  There will be a substantial number of packages that support triple-DES but haven't been upgraded to AES, and I would expect that situation to last for a couple of years or more.  So anyone who simply fires off a message encrypted in AES without checking first is taking the risk that his message can't be read.

In order to facilitate an orderly transition, I would suggest that we specify a date certain, after which the default algorithm would be 256-bit AES, rather than triple-DES.  That certainly wouldn't be difficult to implement.  Assuming that AES is formally endorsed some time in the next couple of months (I don't know the exact time line they are on), what would people think about April 1, 2004? That would provide a generous 18 months for a vendor to release their next version, and another 18+ months for users to adopt it.  Since most e-mail packages are based on underlying crypto packages that can be downloaded via the web, I think that would be more than enough time.

Of course if someone chooses to do so, they can explicitly request (or force) the use of AES prior to that date, but at least the default would be taken care of nicely.

Bob



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id FAA09785 for ietf-smime-bks; Wed, 29 Nov 2000 05:26:30 -0800 (PST)
Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA09776 for <[e-mail]>; Wed, 29 Nov 2000 05:26:27 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 29 Nov 2000 13:27:48 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA13987; Wed, 29 Nov 2000 08:27:56 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id <VL6G53QS>; Wed, 29 Nov 2000 08:27:55 -0500
Message-ID: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>
Cc: [e-mail]
Subject: RE: RSA vs. DSA MUST
Date: Wed, 29 Nov 2000 08:27:33 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob, all:

NIST's announcement of FIPS 186-2
(http://csrc.nist.gov/csrc/fedstandards.html) explicitly recognizes PKCS #1
for a transitional period through mid-2001.  The topic of X9.31 vs. PKCS #1
was discussed at the June meeting of the U.S. Federal PKI Technical Working
Group, leading to a recommendation which was to be communicated (see also
minutes at http://csrc.nist.gov/pki/twg/y2000/twg00_6.htm) that FIPS 186-2
should be changed or interpreted to allow Federal use of PKCS #1 v. 1.5 for
a significant additional period, perhaps 5 years or more, anticipating a
migration after PSS signature definitions are suitably mature and stable.  I
don't know how this recommendation will act to impact the future of the FIPS
186 specification, but believe that it indicates an influential position
from a significant U.S. Government user community. 

X9.31 doesn't appear to have been widely adopted, and I'm not aware that its
padding structure offers security properties sufficiently different relative
to PKCS #1 v. 1.5 to motivate a mandated switch to X9.31 (with associated
installed base impact) at this point.  A later migration to PSS, which
affords qualitatively different provable security properties than either
PKCS #1 v. 1.5 or X9.31 is, I believe, a more compelling case.

--jl

> -----Original Message-----
> From: Bob Jueneman [mailto:[e-mail]]
> Sent: Tuesday, November 28, 2000 6:34 PM
> To: [e-mail]; [e-mail]
> Subject: Re: RSA vs. DSA MUST
> 
> 
> Chicken and egg is exactly the situation we find ourselves 
> in.  Implementors certainly want to support their customers, 
> but don't want to be "required" by standards to implement 
> algorithms that no one uses or are willing to pay for.
> 
> Ozan Gonenc also makes a good point in suggesting that 
> perhaps the MUST algorithms be limited to FIPS approved 
> algorithms.  I'm a slightly concerned that this may be too 
> US-centric a view, but on the other hand I haven't heard of 
> any other governments or customers requiring or promoting any 
> other algorithms, except for 
> unpublished/proprietary/classified algorithms used in certain 
> restricted sectors.  (An exception might be GOST, but so far 
> we can't even get the Russians to agree to pay anything for 
> the capability., much less anyone else) So maybe limiting the 
> MUST algorithms to a subset of the FIPS-approved list is 
> acceptable.  At least the FIPS listing implies a rather 
> serious degree of vetting as to the security of the 
> algorithms, which is something I don't think the IETF is 
> institutionally capable of, not withstanding the 
> cryptographic expertise of some of the members.
> 
> The point about having at least one algorithm in the suite 
> that could be used if RSA were suddenly shown to be seriously 
> flawed is also valid, so long as we don't get carried away 
> with the list!
> 
> FIPS 186-2 includes DSA, ANSI X9.31 RSA, and X9.31 Elliptic 
> Curve DSA; but not PKCS-1 RSA, the one interoperable 
> algorithm that everyone is using presently!
> 
> Hmm.
> 
> I'm not necessarily advocating this position -- I might like 
> to think about it some more myself -- but just for the sake 
> of argument and to take the pulse, what would people think of 
> making ANSI X9.31 RSA a MUST,  X9.31 EC-DSA a SHOULD, and DSA 
> and PKCS-1 RSA a MAY?
> 
> It is my understanding that X9.31 RSA is considered to be 
> superior to PKCS-1 RSA in terms of resistance to certain 
> forms of attack, and should not be that great a stretch for 
> existing RSA implementations, and hence the MUST. We wouldn't 
> deprecate PKCS-1 RSA (at least not yet), since it must 
> continue to be supported for backwards compatibility.
> 
> This wouldn't deprecate DSA either, but it wouldn't be 
> required  for people outside of the (quite limited) community 
> of interest presently using it. 
> 
> EC-DSA certainly beats regular DSA in terms of speed and size 
> and deserves to be included in its own right, but I'm not 
> entirely clear as to the patent situation, hence the SHOULD 
> and not a MUST.
> 
> In the area of symmetric algorithms, as soon as Rijndael is 
> officially certified as the AES algorithm I believe we should 
> promote AES to MUST, along with triple-DES and single DES for 
> backwards compatibility.  ( haven't heard of anyone clamoring 
> for SKIPJACK, so I think it can safely be ignored in favor of 
> triple-DES and/or AES.)
> 
> Likewise, I think we will have to add SHA-386 and SHA-512 as 
> MUST algorithms, along with SHA-1, and probably deprecate MD2 and MD5.
> 
> What think ye?
> 
> Bob
> 
> 
> >Enzo has captured the chicken-and-egg essence of my concern. 
>  The U.S.
> >Government has a requirement to purchase products which support FIPS
> >186-2 algorithms (this includes DSA and ANSI X9.31 RSA, but 
> not PKCS-1
> >RSA).  And, at least in the DoD, we have requirements coming from our
> >customers to be algorithm independent:
> >
> >  "PKI must support a variety of public key cryptographic algorithms
> >   both in the public/private key pairs created and certified by PKI,
> >   and in the algorithms used to apply digital signatures to 
> certificates
> >   and other PKI products.  PKI must support the concurrent 
> use of several
> >   digital signature algorithms for issuing certificates and 
> must be able
> >   to migrate over time to using new signature algorithms."
> >
> >           -- DoD PKI Operational Requirements Document, 22 
> October 2000
> >
> >
> >There is also the fact that DSA signatures are significantly smaller
> >than RSA signatures, especially as we move to public keys 
> above 1024 bits
> >and the signature could be bigger than the entire 
> to-be-signed certificate.
> >This doesn't matter in many environments, but it does in some.
> >
> >If vendors look at what certificates have already been 
> issued to decide
> >what certificates to support in products under development, 
> we will never
> >evolve.  I favor keeping DSA (in addition to RSA) as a MUST 
> for S/MIME
> >clients because algorithm independence is valuable in and of itself.
> >
> >Dave
> >
> >
> >
> >> From: "Enzo Michelangeli" <[e-mail]> 
> >> 
> >> Well, there is one problem, and it's due to the 
> store-and-forwad nature of
> >> e-mail which prevents negotiation, making it impossible to 
> know whether a
> >> given algorithm is supported by a new recipient (think, 
> e.g., of signed
> >> messages sent to mailing list). The result is that 
> everybody ends up using
> >> ONLY the common denominator, i.e. the "MUST" algorithms. 
> Incidentally, this
> >> was precisely the root of the trouble with 40-bit security 
> in the bad old
> >> days: a sort of Grisham's Law for algorithms...
> >> In my opinion, "MAY" algorithms are pretty useless in 
> non-interactive
> >> contexts, and if DSA is not kept as a "MUST" (my preferred 
> choice), it might
> >> as well be dropped altogether.
> >> 
> >> Enzo
> >
> 


Received: by ns.secondary.com (8.9.3/8.9.3) id DAA01561 for ietf-smime-bks; Wed, 29 Nov 2000 03:30:18 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA01557 for <[e-mail]>; Wed, 29 Nov 2000 03:30:16 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02154; Wed, 29 Nov 2000 06:31:45 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-x400transport-01.txt
Date: Wed, 29 Nov 2000 06:31:45 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Transporting S/MIME Objects in X.400
	Author(s)	: P. Hoffman, C. Bonatti
	Filename	: draft-ietf-smime-x400transport-01.txt
	Pages		: 
	Date		: 28-Nov-00
	
This document describes protocol options for conveying CMS-protected
objects associated with S/MIME version 3 over an X.400 message transfer
system.

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA01548 for ietf-smime-bks; Wed, 29 Nov 2000 03:30:13 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA01540 for <[e-mail]>; Wed, 29 Nov 2000 03:30:12 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02101; Wed, 29 Nov 2000 06:31:41 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-x400wrap-01.txt
Date: Wed, 29 Nov 2000 06:31:41 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Securing X.400 Content with S/MIME
	Author(s)	: P. Hoffman, C. Bonatti
	Filename	: draft-ietf-smime-x400wrap-01.txt
	Pages		: 
	Date		: 28-Nov-00
	
This document describes a protocol for adding cryptographic signature
and encryption services to X.400 content.

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA01523 for ietf-smime-bks; Wed, 29 Nov 2000 03:30:10 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA01503 for <[e-mail]>; Wed, 29 Nov 2000 03:30:07 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02047; Wed, 29 Nov 2000 06:31:37 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-examples-05.txt
Date: Wed, 29 Nov 2000 06:31:36 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Examples of S/MIME Messages
	Author(s)	: P. Hoffman
	Filename	: draft-ietf-smime-examples-05.txt
	Pages		: 8
	Date		: 28-Nov-00
	
This document gives examples of message bodies formatted using S/MIME.
Specifically, it has examples of Cryptographic Message Syntax (CMS)
objects, S/MIME messages (including the MIME formatting), and Enhanced
Security Services for S/MIME (ESS). It includes examples of most or all
common CMS and ESS formats; in addition, it gives examples that show
common pitfalls in implementing CMS. The purpose of this document is to
help increase interoperability for S/MIME and other protocols that rely
on CMS.
This draft is being discussed on the 'ietf-smime' mailing list.  To
join the list, send a message to <[e-mail]> with the
single word 'subscribe' in the body of the message.  Also, there is a
Web site for the mailing list at <http://www.imc.org/ietf-smime/>.

This draft is being discussed on the 'ietf-smime' mailing list.  To
join the list, send a message to <[e-mail]> with the
single word 'subscribe' in the body of the message.  Also, there is a
Web site for the mailing list at <http://www.imc.org/ietf-smime/>.

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-examples-05.txt

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

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

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id DAA01485 for ietf-smime-bks; Wed, 29 Nov 2000 03:30:03 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA01481 for <[e-mail]>; Wed, 29 Nov 2000 03:30:02 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02003; Wed, 29 Nov 2000 06:31:31 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-compression-03.txt
Date: Wed, 29 Nov 2000 06:31:31 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Compressed Data Content Type for S/MIME
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-smime-compression-03.txt
	Pages		: 
	Date		: 28-Nov-00
	
The Cryptographic Message Syntax data format doesn't currently contain
any provisions for compressing data before processing it. Compressing
data before transmission provides a number of advantages including the
elimination of data redundancy which could help an attacker, speeding
up processing by reducing the amount of data to be processed by later
steps such as signing or encryption, and reducing overall message
size. Although there have been proposals for adding compression at
other levels (for example at the MIME or SSL level) these don't
address the problem of compression of CMS content unless the
compression is supplied by an external means (for example by
intermixing MIME and CMS).  This document defines a format for using
compressed data as a CMS content type.

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-compression-03.txt

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

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

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id RAA20720 for ietf-smime-bks; Tue, 28 Nov 2000 17:43:08 -0800 (PST)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA20714 for <[e-mail]>; Tue, 28 Nov 2000 17:43:03 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id OAA06946; Wed, 29 Nov 2000 14:43:45 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97546223703233>; Wed, 29 Nov 2000 14:43:57 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: RSA vs. DSA MUST
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Wed, 29 Nov 2000 14:43:57 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Bob Jueneman" <[e-mail]> writes:

>I'm not necessarily advocating this position -- I might like to think about it
>some more myself -- but just for the sake of argument and to take the pulse,
>what would people think of making ANSI X9.31 RSA a MUST,  X9.31 EC-DSA a
>SHOULD, and DSA and PKCS-1 RSA a MAY?

How about trying to make the spec at least vaguely approximate reality in the
choice of algorithms?  It doesn't really matter if you include requirements
like "MUST DSA OR WE WILL KILL YOU[0], SHOULD NOT RSA", in practice the world
will interpret it as "MUST RSA, MAY DSA, SHOULD NOT X9.42 DH, BWAHAHAHAHAHA
X9.31 RSA" no matter what it says in the RFC (I think IBM does X9.31 in CCA but
does anything else in existence implement this?).  

I've been sitting here watching this debate go on and on, but since no matter
what you put in the RFC the market will interpret it as MUST RSA and various
levels of deprecation for anything else maybe we could get Markov Chaney to
continue the debate for a while just for forms sake and then after enough
messages have been exchanged to satisfy everyone either put text in the RFC
which accepts what everyone's going to do anyway or which specifies all sorts
of options and alternatives secure in the knowledge that implementors will
ignore it and do what the market wants/expects, which ain't DSA or X9.31 RSA.

Peter.

[0] RFC 2026bis, "When MUST just isn't enough".




Received: by ns.secondary.com (8.9.3/8.9.3) id RAA20649 for ietf-smime-bks; Tue, 28 Nov 2000 17:39:27 -0800 (PST)
Received: from china.asiainter.net (asiainter.net [202.84.207.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA20645 for <[e-mail]>; Tue, 28 Nov 2000 17:39:25 -0800 (PST)
Received: (qmail 18123 invoked from network); 29 Nov 2000 01:40:50 -0000
Received: from unknown (HELO em) (203.161.252.186) by asiainter.net with SMTP; 29 Nov 2000 01:40:50 -0000
Message-ID: <009101c059a5$5ba32bb0$6000a8c0@em>
From: "Enzo Michelangeli" <[e-mail]>
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: RSA vs. DSA MUST
Date: Wed, 29 Nov 2000 09:39:31 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----- Original Message -----
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Wednesday, November 29, 2000 1:22 AM
Subject: Re: RSA vs. DSA MUST


> Although it isn't strictly interactive in the sense that SSL is,
> the SMIMECapabilities attribute allows the originator of a message
> to indicate his preference as to encryption algorithms, including
> 40-bit RC4 vs. 56-bit DES > vs. 128-bit whatever vs. 196-bit
> triple-DES (and soon, presumably, 256-bit AES).

Yes, but on the open Internet most certificates are sent as part of the
message (presently in PKCS#7 format), not retrieved from global directories
as the X.500 folks initially hoped. In that context, the recipient would
have to send an initial signed message to the sender to indicate the user
agent's capabilities: and in most cases (like one I mentioned of the mailing
list) that's just not viable.

Enzo




Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA20065 for ietf-smime-bks; Tue, 28 Nov 2000 17:10:55 -0800 (PST)
Received: from china.asiainter.net (asiainter.net [202.84.207.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA20061 for <[e-mail]>; Tue, 28 Nov 2000 17:10:52 -0800 (PST)
Received: (qmail 8735 invoked from network); 29 Nov 2000 01:12:16 -0000
Received: from unknown (HELO em) (203.161.252.186) by asiainter.net with SMTP; 29 Nov 2000 01:12:16 -0000
Message-ID: <004d01c059a1$5e0904f0$6000a8c0@em>
From: "Enzo Michelangeli" <[e-mail]>
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: RSA vs. DSA MUST
Date: Wed, 29 Nov 2000 09:11:16 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Considering that the patents issues with RSA have gone away, and that RSA
Security in the past has been willing to grant royalty-free RC2 licenses for
S/MIME products, is there any remaining reason for not requiring complete
S/MIME v.2 backward compatibility as a MUST? If there aren't, I would add to
the MUST list at least D-H, DSA and 3DES, just to prevent a global shutdown
of secure e-mail if tomorrow someone finds flaws in one of the v.2
algorithms.

I don't think that implementing some additional well understood and
royalty-free algorithm would represent such a large cost to the industry,
especially considering the wide availability of OpenSource libraries,
licensed under BSD license or even more liberal terms, that can be used as a
building block.

Enzo

----- Original Message -----
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Sent: Wednesday, November 29, 2000 7:33 AM
Subject: Re: RSA vs. DSA MUST


> Chicken and egg is exactly the situation we find ourselves in.
Implementors certainly want to support their customers, but don't want to be
"required" by standards to implement algorithms that no one uses or are
willing to pay for.
>
> Ozan Gonenc also makes a good point in suggesting that perhaps the MUST
algorithms be limited to FIPS approved algorithms.  I'm a slightly concerned
that this may be too US-centric a view, but on the other hand I haven't
heard of any other governments or customers requiring or promoting any other
algorithms, except for unpublished/proprietary/classified algorithms used in
certain restricted sectors.  (An exception might be GOST, but so far we
can't even get the Russians to agree to pay anything for the capability.,
much less anyone else) So maybe limiting the MUST algorithms to a subset of
the FIPS-approved list is acceptable.  At least the FIPS listing implies a
rather serious degree of vetting as to the security of the algorithms, which
is something I don't think the IETF is institutionally capable of, not
withstanding the cryptographic expertise of some of the members.
>
> The point about having at least one algorithm in the suite that could be
used if RSA were suddenly shown to be seriously flawed is also valid, so
long as we don't get carried away with the list!
>
> FIPS 186-2 includes DSA, ANSI X9.31 RSA, and X9.31 Elliptic Curve DSA; but
not PKCS-1 RSA, the one interoperable algorithm that everyone is using
presently!
>
> Hmm.
>
> I'm not necessarily advocating this position -- I might like to think
about it some more myself -- but just for the sake of argument and to take
the pulse, what would people think of making ANSI X9.31 RSA a MUST,  X9.31
EC-DSA a SHOULD, and DSA and PKCS-1 RSA a MAY?
>
> It is my understanding that X9.31 RSA is considered to be superior to
PKCS-1 RSA in terms of resistance to certain forms of attack, and should not
be that great a stretch for existing RSA implementations, and hence the
MUST. We wouldn't deprecate PKCS-1 RSA (at least not yet), since it must
continue to be supported for backwards compatibility.
>
> This wouldn't deprecate DSA either, but it wouldn't be required  for
people outside of the (quite limited) community of interest presently using
it.
>
> EC-DSA certainly beats regular DSA in terms of speed and size and deserves
to be included in its own right, but I'm not entirely clear as to the patent
situation, hence the SHOULD and not a MUST.
>
> In the area of symmetric algorithms, as soon as Rijndael is officially
certified as the AES algorithm I believe we should promote AES to MUST,
along with triple-DES and single DES for backwards compatibility.  ( haven't
heard of anyone clamoring for SKIPJACK, so I think it can safely be ignored
in favor of triple-DES and/or AES.)
>
> Likewise, I think we will have to add SHA-386 and SHA-512 as MUST
algorithms, along with SHA-1, and probably deprecate MD2 and MD5.
>
> What think ye?
>
> Bob
>
>
> >Enzo has captured the chicken-and-egg essence of my concern.  The U.S.
> >Government has a requirement to purchase products which support FIPS
> >186-2 algorithms (this includes DSA and ANSI X9.31 RSA, but not PKCS-1
> >RSA).  And, at least in the DoD, we have requirements coming from our
> >customers to be algorithm independent:
> >
> >  "PKI must support a variety of public key cryptographic algorithms
> >   both in the public/private key pairs created and certified by PKI,
> >   and in the algorithms used to apply digital signatures to certificates
> >   and other PKI products.  PKI must support the concurrent use of
several
> >   digital signature algorithms for issuing certificates and must be able
> >   to migrate over time to using new signature algorithms."
> >
> >           -- DoD PKI Operational Requirements Document, 22 October 2000
> >
> >
> >There is also the fact that DSA signatures are significantly smaller
> >than RSA signatures, especially as we move to public keys above 1024 bits
> >and the signature could be bigger than the entire to-be-signed
certificate.
> >This doesn't matter in many environments, but it does in some.
> >
> >If vendors look at what certificates have already been issued to decide
> >what certificates to support in products under development, we will never
> >evolve.  I favor keeping DSA (in addition to RSA) as a MUST for S/MIME
> >clients because algorithm independence is valuable in and of itself.
> >
> >Dave
> >
> >
> >
> >> From: "Enzo Michelangeli" <[e-mail]>
> >>
> >> Well, there is one problem, and it's due to the store-and-forwad nature
of
> >> e-mail which prevents negotiation, making it impossible to know whether
a
> >> given algorithm is supported by a new recipient (think, e.g., of signed
> >> messages sent to mailing list). The result is that everybody ends up
using
> >> ONLY the common denominator, i.e. the "MUST" algorithms. Incidentally,
this
> >> was precisely the root of the trouble with 40-bit security in the bad
old
> >> days: a sort of Grisham's Law for algorithms...
> >> In my opinion, "MAY" algorithms are pretty useless in non-interactive
> >> contexts, and if DSA is not kept as a "MUST" (my preferred choice), it
might
> >> as well be dropped altogether.
> >>
> >> Enzo
> >
>






Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA17027 for ietf-smime-bks; Tue, 28 Nov 2000 15:33:10 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA17020 for <[e-mail]>; Tue, 28 Nov 2000 15:33:08 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 28 Nov 2000 16:33:57 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Tue, 28 Nov 2000 16:33:50 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: RSA vs. DSA MUST
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA17021
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chicken and egg is exactly the situation we find ourselves in.  Implementors certainly want to support their customers, but don't want to be "required" by standards to implement algorithms that no one uses or are willing to pay for.

Ozan Gonenc also makes a good point in suggesting that perhaps the MUST algorithms be limited to FIPS approved algorithms.  I'm a slightly concerned that this may be too US-centric a view, but on the other hand I haven't heard of any other governments or customers requiring or promoting any other algorithms, except for unpublished/proprietary/classified algorithms used in certain restricted sectors.  (An exception might be GOST, but so far we can't even get the Russians to agree to pay anything for the capability., much less anyone else) So maybe limiting the MUST algorithms to a subset of the FIPS-approved list is acceptable.  At least the FIPS listing implies a rather serious degree of vetting as to the security of the algorithms, which is something I don't think the IETF is institutionally capable of, not withstanding the cryptographic expertise of some of the members.

The point about having at least one algorithm in the suite that could be used if RSA were suddenly shown to be seriously flawed is also valid, so long as we don't get carried away with the list!

FIPS 186-2 includes DSA, ANSI X9.31 RSA, and X9.31 Elliptic Curve DSA; but not PKCS-1 RSA, the one interoperable algorithm that everyone is using presently!

Hmm.

I'm not necessarily advocating this position -- I might like to think about it some more myself -- but just for the sake of argument and to take the pulse, what would people think of making ANSI X9.31 RSA a MUST,  X9.31 EC-DSA a SHOULD, and DSA and PKCS-1 RSA a MAY?

It is my understanding that X9.31 RSA is considered to be superior to PKCS-1 RSA in terms of resistance to certain forms of attack, and should not be that great a stretch for existing RSA implementations, and hence the MUST. We wouldn't deprecate PKCS-1 RSA (at least not yet), since it must continue to be supported for backwards compatibility.

This wouldn't deprecate DSA either, but it wouldn't be required  for people outside of the (quite limited) community of interest presently using it. 

EC-DSA certainly beats regular DSA in terms of speed and size and deserves to be included in its own right, but I'm not entirely clear as to the patent situation, hence the SHOULD and not a MUST.

In the area of symmetric algorithms, as soon as Rijndael is officially certified as the AES algorithm I believe we should promote AES to MUST, along with triple-DES and single DES for backwards compatibility.  ( haven't heard of anyone clamoring for SKIPJACK, so I think it can safely be ignored in favor of triple-DES and/or AES.)

Likewise, I think we will have to add SHA-386 and SHA-512 as MUST algorithms, along with SHA-1, and probably deprecate MD2 and MD5.

What think ye?

Bob


>Enzo has captured the chicken-and-egg essence of my concern.  The U.S.
>Government has a requirement to purchase products which support FIPS
>186-2 algorithms (this includes DSA and ANSI X9.31 RSA, but not PKCS-1
>RSA).  And, at least in the DoD, we have requirements coming from our
>customers to be algorithm independent:
>
>  "PKI must support a variety of public key cryptographic algorithms
>   both in the public/private key pairs created and certified by PKI,
>   and in the algorithms used to apply digital signatures to certificates
>   and other PKI products.  PKI must support the concurrent use of several
>   digital signature algorithms for issuing certificates and must be able
>   to migrate over time to using new signature algorithms."
>
>           -- DoD PKI Operational Requirements Document, 22 October 2000
>
>
>There is also the fact that DSA signatures are significantly smaller
>than RSA signatures, especially as we move to public keys above 1024 bits
>and the signature could be bigger than the entire to-be-signed certificate.
>This doesn't matter in many environments, but it does in some.
>
>If vendors look at what certificates have already been issued to decide
>what certificates to support in products under development, we will never
>evolve.  I favor keeping DSA (in addition to RSA) as a MUST for S/MIME
>clients because algorithm independence is valuable in and of itself.
>
>Dave
>
>
>
>> From: "Enzo Michelangeli" <[e-mail]> 
>> 
>> Well, there is one problem, and it's due to the store-and-forwad nature of
>> e-mail which prevents negotiation, making it impossible to know whether a
>> given algorithm is supported by a new recipient (think, e.g., of signed
>> messages sent to mailing list). The result is that everybody ends up using
>> ONLY the common denominator, i.e. the "MUST" algorithms. Incidentally, this
>> was precisely the root of the trouble with 40-bit security in the bad old
>> days: a sort of Grisham's Law for algorithms...
>> In my opinion, "MAY" algorithms are pretty useless in non-interactive
>> contexts, and if DSA is not kept as a "MUST" (my preferred choice), it might
>> as well be dropped altogether.
>> 
>> Enzo
>



Received: by ns.secondary.com (8.9.3/8.9.3) id LAA05633 for ietf-smime-bks; Tue, 28 Nov 2000 11:47:08 -0800 (PST)
Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05628 for <[e-mail]>; Tue, 28 Nov 2000 11:47:06 -0800 (PST)
Received: from [192.168.1.35] ([208.233.228.110]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <[e-mail]> for [e-mail]; Tue, 28 Nov 2000 11:27:50 -0800 (PST)
Date: Tue, 28 Nov 2000 11:29:23 -0800
From: Aram Perez <[e-mail]>
Subject: Re: RSA vs. DSA MUST
In-reply-to: <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David Kemp wrote:

[snip]
> If vendors look at what certificates have already been issued to decide
> what certificates to support in products under development, we will never
> evolve.  I favor keeping DSA (in addition to RSA) as a MUST for S/MIME
> clients because algorithm independence is valuable in and of itself.

Was S/MIME not algorithm independent when DSA was a MUST? How would
substituting DSA with RSA change the independence? DOD could mandate S/MIME
with DSA even if S/MIME requires RSA. Someone could write a S/MIME with DSA
document similar to the ones with IDEA, CAST, etc.

Regards,
Aram Perez



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA02921 for ietf-smime-bks; Tue, 28 Nov 2000 11:17:49 -0800 (PST)
Received: from luc.ab.org (mail.ab.org [209.112.11.37]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA02916 for <[e-mail]>; Tue, 28 Nov 2000 11:17:48 -0800 (PST)
Received: from D00425 ([206.222.76.33]) by luc.ab.org (Netscape Messaging Server 3.6)  with SMTP id AAA95CD1 for <[e-mail]>; Tue, 28 Nov 2000 14:25:03 -0500
From: "Ozan Gonenc" <[e-mail]>
To: <[e-mail]>
Subject: RE: RSA vs. DSA MUST
Date: Tue, 28 Nov 2000 14:17:24 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Is there a study readily available comparing all these FIPS-140 approved
algorithms in question?  I'm sure each one of them have there unique
advantages and disadvantages (i.e. processing speeds, cryptanalysis).
Limiting ourselves to only one algorithm to lessen coding efforts and
simplifying interoperability may be detrimental as new attack methods evolve
day-to-day.  Yes customer-demands is what drives vendor development but what
do you think the customer will demand if a serious RSA vulnerability is
identified when new cryptanalysis technologies become available?  Even as a
rumor or a hoax (i.e. unproven/unofficial RSA crack), customers' demand will
be mail packages with multi-algorithm capability.  A mail agent's capability
to use a variety of algorithms is a major selling point.

I know this may be a little far-fetched but we should keep standards as
accomodating as possible for any future possiblities.  Maybe the limiting
factor should be FIPS approved algorithms...


Regards,

Ozan

______________________________

Ozan Gonenc
IT Security Consultant

AEPOS Technologies Corporation



-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Bob Jueneman
Sent: November 28, 2000 10:21
To: [e-mail]; [e-mail];
[e-mail]; [e-mail]
Subject: RE: RSA vs. DSA MUST


>"Blake Ramsdell" <[e-mail]> writes:
>
>>I do not care strongly, but the strawpoll at the last IETF indicated a
>>preference for "both", and that was the path we were headed down, and that
>>Russ summarized.  Personally, I don't implement it, and I haven't had any
>>customer complaints telling me I should, and the backwards compatibility
>>issues are almost the same as for Diffie-Hellman certs (that is, I have
not
>>seen anyone using them, so chucking them wouldn't break an installed base
of
>>significant size, if at all).
>
>In case this is useful as a data point, in my general wandering around
looking
>for certs on the net the only publicly available DSA certs I've ever found
were
>some old Thawte ones, presumably created just to show'em (all the standard
>Thawte certs are RSA, I don't think I've ever seen the DSA certs actually
used
>to certify anything).  I've also very occasionally come across them being
used
>in closed environments (ie ones where interoperability with the masses
isn't
>really an issue).  I suspect the motivation for a lot of these is that
there's
>a requirement to use a FIPS algorithm and DSA is the only choice.  I can't
see
>a MUST RSA, MAY DSA as being any real problem, it's just recognising what
has
>been reality for the last few years.
>
>Peter.
>
That would certainly be my preference, unless some hitherto-unknown set of
customers waving gobs of money come running out of the woods.

Even MAY language is somewhat troubling -- I continue to believe that the
SMIME group has gotten seriously off track by introducing orphan algorithms
such as CAST, IDEA, symmetric key, password-encryption, etc., etc., that if
implemented would add only incrementally to the coding effort, but would
complicate interoperability testing exponentially.  I wouldn't object to MAY
for DSA, but I would strongly prefer that it not be a MUST.

If DSA is a MUST, then I strongly suspect that we and probably many other
vendors will simply be noncompliant, and that doesn't help anyone,
especially with respect to interoperability.  And isn't that what standards
are all about?

Regards,

Bob

Robert R. Jueneman
Security Architect
Novell, Inc. -- the leading provider of Net services software



Received: by ns.secondary.com (8.9.3/8.9.3) id JAA24139 for ietf-smime-bks; Tue, 28 Nov 2000 09:30:02 -0800 (PST)
Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA24127 for <[e-mail]>; Tue, 28 Nov 2000 09:30:00 -0800 (PST)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id MAA01789 for <[e-mail]>; Tue, 28 Nov 2000 12:06:49 -0500 (EST)
Message-Id: <[e-mail]>
Date: Tue, 28 Nov 2000 12:23:21 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: RSA vs. DSA MUST
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: s/58JT4eiiBmy3uAQ4fStA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Enzo has captured the chicken-and-egg essence of my concern.  The U.S.
Government has a requirement to purchase products which support FIPS
186-2 algorithms (this includes DSA and ANSI X9.31 RSA, but not PKCS-1
RSA).  And, at least in the DoD, we have requirements coming from our
customers to be algorithm independent:

  "PKI must support a variety of public key cryptographic algorithms
   both in the public/private key pairs created and certified by PKI,
   and in the algorithms used to apply digital signatures to certificates
   and other PKI products.  PKI must support the concurrent use of several
   digital signature algorithms for issuing certificates and must be able
   to migrate over time to using new signature algorithms."

           -- DoD PKI Operational Requirements Document, 22 October 2000


There is also the fact that DSA signatures are significantly smaller
than RSA signatures, especially as we move to public keys above 1024 bits
and the signature could be bigger than the entire to-be-signed certificate.
This doesn't matter in many environments, but it does in some.

If vendors look at what certificates have already been issued to decide
what certificates to support in products under development, we will never
evolve.  I favor keeping DSA (in addition to RSA) as a MUST for S/MIME
clients because algorithm independence is valuable in and of itself.

Dave



> From: "Enzo Michelangeli" <[e-mail]>
> 
> Well, there is one problem, and it's due to the store-and-forwad nature of
> e-mail which prevents negotiation, making it impossible to know whether a
> given algorithm is supported by a new recipient (think, e.g., of signed
> messages sent to mailing list). The result is that everybody ends up using
> ONLY the common denominator, i.e. the "MUST" algorithms. Incidentally, this
> was precisely the root of the trouble with 40-bit security in the bad old
> days: a sort of Grisham's Law for algorithms...
> In my opinion, "MAY" algorithms are pretty useless in non-interactive
> contexts, and if DSA is not kept as a "MUST" (my preferred choice), it might
> as well be dropped altogether.
> 
> Enzo



Received: by ns.secondary.com (8.9.3/8.9.3) id JAA23487 for ietf-smime-bks; Tue, 28 Nov 2000 09:21:48 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA23482 for <[e-mail]>; Tue, 28 Nov 2000 09:21:47 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 28 Nov 2000 10:22:40 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Tue, 28 Nov 2000 10:22:36 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: RSA vs. DSA MUST
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id JAA23484
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>Well, there is one problem, and it's due to the store-and-forward nature of
>e-mail which prevents negotiation, making it impossible to know whether a
>given algorithm is supported by a new recipient (think, e.g., of signed
>messages sent to mailing list). The result is that everybody ends up using
>ONLY the common denominator, i.e. the "MUST" algorithms. Incidentally, this
>was precisely the root of the trouble with 40-bit security in the bad old
>days: a sort of Gresham's Law for algorithms...
>In my opinion, "MAY" algorithms are pretty useless in non-interactive
>contexts, and if DSA is not kept as a "MUST" (my preferred choice), it might
>as well be dropped altogether.
>
>Enzo
>
Although it isn't strictly interactive in the sense that SSL is, the SMIMECapabilities attribute allows the originator of a message to indicate his preference as to encryption algorithms, including 40-bit RC4 vs. 56-bit DES vs. 128-bit whatever vs. 196-bit triple-DES (and soon, presumably, 256-bit AES).   (Granted, some implementations ignore the attribute and default to the lowest common denominator (boo, hiss), and others use whatever algorithm and key size the originator selects, regardless of what the recipient specified.)

I don't have the text in front of me, but isn't it possible to indicate the preferred key exchange and signature algorithms (and hashing algorithms, in order to handle SHA-384 and SHA-512) in the same manner?

If not, it probably ought to be amended.

Bob



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA21662 for ietf-smime-bks; Tue, 28 Nov 2000 09:06:38 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA21653 for <[e-mail]>; Tue, 28 Nov 2000 09:06:35 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 28 Nov 2000 10:07:17 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Tue, 28 Nov 2000 10:07:17 -0700
From: "Tolga Acar" <[e-mail]>
To: <[e-mail]>
Subject: Re: RSA vs. DSA MUST
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_C299D655.CBAAC9F1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_C299D655.CBAAC9F1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable


> In case this is useful as a data point, in my general wandering around =
looking
> for certs on the net the only publicly available DSA certs I've ever =
found were
> some old Thawte ones, presumably created just to show'em (all the =
standard
> Thawte certs are RSA, I don't think I've ever seen the DSA certs =
actually used
> to certify anything).  I've also very occasionally come across them =
being used
> in closed environments (ie ones where interoperability with the masses =
isn't
> really an issue).  I suspect the motivation for a lot of these is that =
there's
> a requirement to use a FIPS algorithm and DSA is the only choice.  I =
can't see
> a MUST RSA, MAY DSA as being any real problem, it's just recognising =
what has
> been reality for the last few years.

DSA is not the ONLY asymmetric algorithm certifiable in FIPS 140-1/2, as =
it references any algorithm published/referenced in a FIPS;  X9.31 and =
X9.62 are also specified in FIPS 186-2.
Remember that DSS it not DSA.
Looking forward (that's what this is about, isn't it?), there are three =
asymmetric algorithms in FIPS 68-2: DSA, X9.31 RSA, and X9.62 ECDSA.
So, the motivation for a lot of those certificates based on FIPS 186-1 and =
FIPS 140-1, is not there anymore.
It is enough to support one of them for FIPS purposes, then the most =
common one, RSA, should do fine. NIST certainly does not mandate all of =
them (FIPS 186-2, page 3, line 3).
Effective as of July 27, 2000, and with the prescribed transition period =
of FIPS 186-2 from July 27 2000 to July 27 2001, that should give enough =
time to make changes in a product line.

- Tolga

--=_C299D655.CBAAC9F1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1"=
>
<META content=3D"MSHTML 5.50.4522.1800" name=3DGENERATOR></HEAD>
<BODY style=3D"MARGIN-TOP: 2px; FONT: 10pt Arial; MARGIN-LEFT: 2px">
<DIV><BR>&gt; In case this is useful as a data point, in my general =
wandering=20
around looking<BR>&gt; for certs on the net the only publicly available =
DSA=20
certs I've ever found were<BR>&gt; some old Thawte ones, presumably =
created just=20
to show'em (all the standard<BR>&gt; Thawte certs are RSA, I don't think =
I've=20
ever seen the DSA certs actually used<BR>&gt; to certify anything).&nbsp; =
I've=20
also very occasionally come across them being used<BR>&gt; in closed=20
environments (ie ones where interoperability with the masses isn't<BR>&gt;=
=20
really an issue).&nbsp; I suspect the motivation for a lot of these is =
that=20
there's<BR>&gt; a requirement to use a FIPS algorithm and DSA is the =
only=20
choice.&nbsp; I can't see<BR>&gt; a MUST RSA, MAY DSA as being any real =
problem,=20
it's just recognising what has<BR>&gt; been reality for the last few=20
years.<BR><BR>DSA is not the ONLY asymmetric algorithm certifiable in =
FIPS=20
140-1/2, as it references any algorithm published/referenced in a =
FIPS;&nbsp;=20
X9.31 and X9.62&nbsp;are also specified in FIPS 186-2.</DIV>
<DIV>Remember that DSS it&nbsp;not DSA.</DIV>
<DIV>Looking forward (that's what this is about, isn't it?), there are =
three=20
asymmetric algorithms in FIPS 68-2: DSA, X9.31 RSA, and X9.62 ECDSA.</DIV>
<DIV>So, the motivation for a lot of those certificates based on FIPS =
186-1 and=20
FIPS 140-1, is not there anymore.</DIV>
<DIV>It is enough to support one of them for FIPS purposes, then the most =
common=20
one, RSA, should&nbsp;do fine. NIST certainly does not mandate all of them =
(FIPS=20
186-2, page 3, line 3).</DIV>
<DIV>Effective as of July 27, 2000, and with the prescribed transition =
period of=20
FIPS 186-2 from July 27 2000 to July 27 2001, that should give enough time =
to=20
make changes in a product line.</DIV>
<DIV>&nbsp;</DIV>
<DIV>- Tolga</DIV></BODY></HTML>

--=_C299D655.CBAAC9F1--


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA11760 for ietf-smime-bks; Tue, 28 Nov 2000 08:07:52 -0800 (PST)
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11756 for <[e-mail]>; Tue, 28 Nov 2000 08:07:51 -0800 (PST)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id eASG0lD04598 for <[e-mail]>; Tue, 28 Nov 2000 08:00:52 -0800 (PST)
Received: from netscape.com ([192.18.120.135]) by dredd.mcom.com (Netscape Messaging Server 4.15 dredd Jun 22 2000 16:29:39) with ESMTP id G4QSUH00.DFT; Tue, 28 Nov 2000 08:08:41 -0800 
Message-ID: <[e-mail]>
Date: Tue, 28 Nov 2000 08:08:41 -0800
From: [e-mail] (Bob Relyea)
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20001108 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: Enzo Michelangeli <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: RSA vs. DSA MUST
References: <[e-mail]> <007a01c058e6$a5ccf910$6000a8c0@em>
Content-Type: multipart/alternative; boundary="------------040104030509030409020307"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------040104030509030409020307
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Enzo Michelangeli wrote:

> really an issue).  I suspect the motivation for a lot of these is that
> 
> there's
> 
>> a requirement to use a FIPS algorithm and DSA is the only choice.  I can't
> 
> see
> 
>> a MUST RSA, MAY DSA as being any real problem, it's just recognising what
> 
> has
> 
>> been reality for the last few years.
> 

We have seen a lot of DSA certificates generated by the U.S. Government. 
What we haven't seen is a lot of DH certificates (The government uses 
KEA, which is a form of DH that uses two DH keys and then skipjack to do 
some key mixing).

> Well, there is one problem, and it's due to the store-and-forwad nature of
> e-mail which prevents negotiation, making it impossible to know whether a
> given algorithm is supported by a new recipient (think, e.g., of signed
> messages sent to mailing list). 

It's even worse for asymetric algorithms. Even if you had information to 
allow a negotiated symetric cipher, you are stuck with the asymetric 
cipher based on the user's certificate.

If we were talking DH, I'd say there isn't much point, but I've seen a 
lot of DSA stuff running around, and suspect, because of FIPs, to see 
more of it. I'd vote to make it MUST.


bob

> 



--------------040104030509030409020307
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit

<html><head></head><body>Enzo Michelangeli wrote:<br>
<blockquote type="cite" cite="mid:007a01c058e6$a5ccf910$6000a8c0@em"><pre wrap="">really an issue).  I suspect the motivation for a lot of these is that<br></pre>
  <pre wrap=""><!---->there's<br></pre>
  <blockquote type="cite"><pre wrap="">a requirement to use a FIPS algorithm and DSA is the only choice.  I can't<br></pre></blockquote>
    <pre wrap=""><!---->see<br></pre>
    <blockquote type="cite"><pre wrap="">a MUST RSA, MAY DSA as being any real problem, it's just recognising what<br></pre></blockquote>
      <pre wrap=""><!---->has<br></pre>
      <blockquote type="cite"><pre wrap="">been reality for the last few years.</pre></blockquote>
        </blockquote>
        <br>
We have seen a lot of DSA certificates generated by the U.S. Government.
What we haven't seen is a lot of DH certificates (The government uses KEA,
which is a form of DH that uses two DH keys and then skipjack to do some
key mixing).<br>
        <br>
        <blockquote type="cite" cite="mid:007a01c058e6$a5ccf910$6000a8c0@em"><pre wrap="">Well, there is one problem, and it's due to the store-and-forwad nature of<br>e-mail which prevents negotiation, making it impossible to know whether a<br>given algorithm is supported by a new recipient (think, e.g., of signed<br>messages sent to mailing list). </pre>
          </blockquote>
It's even worse for asymetric algorithms. Even if you had information to
allow a negotiated symetric cipher, you are stuck with the asymetric cipher
based on the user's certificate.<br>
          <br>
If we were talking DH, I'd say there isn't much point, but I've seen a lot
of DSA stuff running around, and suspect, because of FIPs, to see more of
it. I'd vote to make it MUST.<br>
          <br>
          <br>
bob
          <blockquote type="cite" cite="mid:007a01c058e6$a5ccf910$6000a8c0@em"><pre wrap=""><br></pre>
            </blockquote>
            <br>
            <br>
</body></html>
--------------040104030509030409020307--



Received: by ns.secondary.com (8.9.3/8.9.3) id HAA04685 for ietf-smime-bks; Tue, 28 Nov 2000 07:20:15 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA04681 for <[e-mail]>; Tue, 28 Nov 2000 07:20:13 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 28 Nov 2000 08:20:49 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Tue, 28 Nov 2000 08:20:42 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: RSA vs. DSA MUST
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA04682
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>"Blake Ramsdell" <[e-mail]> writes:
>
>>I do not care strongly, but the strawpoll at the last IETF indicated a
>>preference for "both", and that was the path we were headed down, and that
>>Russ summarized.  Personally, I don't implement it, and I haven't had any
>>customer complaints telling me I should, and the backwards compatibility
>>issues are almost the same as for Diffie-Hellman certs (that is, I have not
>>seen anyone using them, so chucking them wouldn't break an installed base of
>>significant size, if at all).
>
>In case this is useful as a data point, in my general wandering around looking
>for certs on the net the only publicly available DSA certs I've ever found were
>some old Thawte ones, presumably created just to show'em (all the standard
>Thawte certs are RSA, I don't think I've ever seen the DSA certs actually used
>to certify anything).  I've also very occasionally come across them being used
>in closed environments (ie ones where interoperability with the masses isn't
>really an issue).  I suspect the motivation for a lot of these is that there's
>a requirement to use a FIPS algorithm and DSA is the only choice.  I can't see
>a MUST RSA, MAY DSA as being any real problem, it's just recognising what has
>been reality for the last few years.
>
>Peter.
>
That would certainly be my preference, unless some hitherto-unknown set of customers waving gobs of money come running out of the woods.  

Even MAY language is somewhat troubling -- I continue to believe that the SMIME group has gotten seriously off track by introducing orphan algorithms such as CAST, IDEA, symmetric key, password-encryption, etc., etc., that if implemented would add only incrementally to the coding effort, but would complicate interoperability testing exponentially.  I wouldn't object to MAY for DSA, but I would strongly prefer that it not be a MUST.

If DSA is a MUST, then I strongly suspect that we and probably many other vendors will simply be noncompliant, and that doesn't help anyone, especially with respect to interoperability.  And isn't that what standards are all about?

Regards,

Bob

Robert R. Jueneman
Security Architect
Novell, Inc. -- the leading provider of Net services software



Received: by ns.secondary.com (8.9.3/8.9.3) id SAA10224 for ietf-smime-bks; Mon, 27 Nov 2000 18:54:59 -0800 (PST)
Received: from china.asiainter.net (asiainter.net [202.84.207.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA10220 for <[e-mail]>; Mon, 27 Nov 2000 18:54:56 -0800 (PST)
Received: (qmail 10681 invoked from network); 28 Nov 2000 02:55:42 -0000
Received: from unknown (HELO em) (203.161.252.186) by asiainter.net with SMTP; 28 Nov 2000 02:55:42 -0000
Message-ID: <007a01c058e6$a5ccf910$6000a8c0@em>
From: "Enzo Michelangeli" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: RSA vs. DSA MUST
Date: Tue, 28 Nov 2000 10:54:43 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----- Original Message -----
From: "Peter Gutmann" <[e-mail]>
To: <[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>
Sent: Tuesday, November 28, 2000 2:10 PM
Subject: RE: RSA vs. DSA MUST


> In case this is useful as a data point, in my general wandering around
looking
> for certs on the net the only publicly available DSA certs I've ever found
were
> some old Thawte ones, presumably created just to show'em (all the standard
> Thawte certs are RSA, I don't think I've ever seen the DSA certs actually
used
> to certify anything).  I've also very occasionally come across them being
used
> in closed environments (ie ones where interoperability with the masses
isn't
> really an issue).  I suspect the motivation for a lot of these is that
there's
> a requirement to use a FIPS algorithm and DSA is the only choice.  I can't
see
> a MUST RSA, MAY DSA as being any real problem, it's just recognising what
has
> been reality for the last few years.

Well, there is one problem, and it's due to the store-and-forwad nature of
e-mail which prevents negotiation, making it impossible to know whether a
given algorithm is supported by a new recipient (think, e.g., of signed
messages sent to mailing list). The result is that everybody ends up using
ONLY the common denominator, i.e. the "MUST" algorithms. Incidentally, this
was precisely the root of the trouble with 40-bit security in the bad old
days: a sort of Grisham's Law for algorithms...
In my opinion, "MAY" algorithms are pretty useless in non-interactive
contexts, and if DSA is not kept as a "MUST" (my preferred choice), it might
as well be dropped altogether.

Enzo




Received: by ns.secondary.com (8.9.3/8.9.3) id RAA08629 for ietf-smime-bks; Mon, 27 Nov 2000 17:21:41 -0800 (PST)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA08621 for <[e-mail]>; Mon, 27 Nov 2000 17:21:30 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id OAA10456; Tue, 28 Nov 2000 14:10:44 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97537385624891>; Tue, 28 Nov 2000 14:10:56 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: RSA vs. DSA MUST
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Tue, 28 Nov 2000 14:10:56 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

>I do not care strongly, but the strawpoll at the last IETF indicated a
>preference for "both", and that was the path we were headed down, and that
>Russ summarized.  Personally, I don't implement it, and I haven't had any
>customer complaints telling me I should, and the backwards compatibility
>issues are almost the same as for Diffie-Hellman certs (that is, I have not
>seen anyone using them, so chucking them wouldn't break an installed base of
>significant size, if at all).

In case this is useful as a data point, in my general wandering around looking
for certs on the net the only publicly available DSA certs I've ever found were
some old Thawte ones, presumably created just to show'em (all the standard
Thawte certs are RSA, I don't think I've ever seen the DSA certs actually used
to certify anything).  I've also very occasionally come across them being used
in closed environments (ie ones where interoperability with the masses isn't
really an issue).  I suspect the motivation for a lot of these is that there's
a requirement to use a FIPS algorithm and DSA is the only choice.  I can't see
a MUST RSA, MAY DSA as being any real problem, it's just recognising what has
been reality for the last few years.

Peter.



Received: by ns.secondary.com (8.9.3/8.9.3) id QAA08126 for ietf-smime-bks; Mon, 27 Nov 2000 16:50:46 -0800 (PST)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA08122 for <[e-mail]>; Mon, 27 Nov 2000 16:50:45 -0800 (PST)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.6)); Mon, 27 Nov 2000 16:51:38 -0800
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2650.21) id <XJ563YFM>; Mon, 27 Nov 2000 16:51:37 -0800
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: RSA vs. DSA MUST
Date: Mon, 27 Nov 2000 16:51:28 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 163DDE1028396-01-01
Content-Type: text/plain;  charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I do not care strongly, but the strawpoll at the last IETF indicated a
preference for "both", and that was the path we were headed down, and that
Russ summarized.  Personally, I don't implement it, and I haven't had any
customer complaints telling me I should, and the backwards compatibility
issues are almost the same as for Diffie-Hellman certs (that is, I have not
seen anyone using them, so chucking them wouldn't break an installed base of
significant size, if at all).

Blake

-----Original Message-----
From: Bob Jueneman [mailto:[e-mail]]
Sent: Monday, November 27, 2000 3:04 PM
To: [e-mail]; [e-mail]
Subject: RSA vs. DSA MUST


David, is the issue whether RSA should REPLACE DSA as a MUST, as opposed to
merely adding an additional MUST for RSA for signatures?

I doubt that there would be any strong disagreement about adding RSA as a
MUST, since it has been a commercial requirement and de facto standard all
along, regardless of IETF politics.

But other than the patent issues, is there still a strong technical,
marketing or other consensus in favor of continuing DSA as a MUST?

To date, we haven't implemented DSA in GroupWise, nor in the Novell Cert.
Server, due to the complete absence of customer demand.  In fact, when we
looked around, we couldn't find any certificates that used DSA (granted, we
probably didn't look very hard.)

Do any of the US DoD PKI or e-mail initiatives have any serious plans to
MANDATE the exclusive use of DSA?  

Does anyone else care strongly?

Regards,

Bob

Robert R. Jueneman
Security Architect
Novell, Inc -- the leading provider of Net services software



>>> "David P. Kemp" <[e-mail]> 11/27/00 01:49PM >>>

> 	Title		: S/MIME Version 3.1 Certificate Profile Addendum
> 	Author(s)	: B. Ramsdell
> 	Filename	: draft-ietf-smime-v31cert-00.txt
> 	Pages		: 
> 	Date		: 22-Nov-00
> 	
> In light of the expiration of the primary RSA patent, it is proposed
> that the RSA algorithm replace the DSS and Diffie-Hellman as the MUST
> implement algorithms in the S/MIME profile. This draft will describe
> only the proposed changes to the S/MIME Version 3 Certificate Handling
> RFC [SMIMEV3CERT], and the rest of that RFC will remain identical.


Did I miss the discussion and consensus on this?

I was under the impression that RSA does not replace DSA as a
MUST-implement, rather RSA becomes an additional MUST for signatures:


> Russ Housley <[e-mail]> on 07/31/2000 05:04:52 PM
>
> Proposed way forward:  Change the mandatory to implement algorithm set to:
>      One-way Hash:  SHA-1 (no change)
>      Signature:     Both DSA and RSA (PKCS#1 v1.5)
>      Key Mgmt: RSA (OAEP)
>      Eencryption:   Triple-DES in CBC mode


The Certificate Profile should reflect the results of the last meeting
and subsequent mail list discussion.






Received: by ns.secondary.com (8.9.3/8.9.3) id PAA06564 for ietf-smime-bks; Mon, 27 Nov 2000 15:03:33 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA06556 for <[e-mail]>; Mon, 27 Nov 2000 15:03:31 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 27 Nov 2000 16:04:20 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Mon, 27 Nov 2000 16:04:16 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RSA vs. DSA MUST
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA06557
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David, is the issue whether RSA should REPLACE DSA as a MUST, as opposed to merely adding an additional MUST for RSA for signatures?

I doubt that there would be any strong disagreement about adding RSA as a MUST, since it has been a commercial requirement and de facto standard all along, regardless of IETF politics.

But other than the patent issues, is there still a strong technical, marketing or other consensus in favor of continuing DSA as a MUST?

To date, we haven't implemented DSA in GroupWise, nor in the Novell Cert. Server, due to the complete absence of customer demand.  In fact, when we looked around, we couldn't find any certificates that used DSA (granted, we probably didn't look very hard.)

Do any of the US DoD PKI or e-mail initiatives have any serious plans to MANDATE the exclusive use of DSA?  

Does anyone else care strongly?

Regards,

Bob

Robert R. Jueneman
Security Architect
Novell, Inc -- the leading provider of Net services software



>>> "David P. Kemp" <[e-mail]> 11/27/00 01:49PM >>>

> 	Title		: S/MIME Version 3.1 Certificate Profile Addendum
> 	Author(s)	: B. Ramsdell
> 	Filename	: draft-ietf-smime-v31cert-00.txt
> 	Pages		: 
> 	Date		: 22-Nov-00
> 	
> In light of the expiration of the primary RSA patent, it is proposed
> that the RSA algorithm replace the DSS and Diffie-Hellman as the MUST
> implement algorithms in the S/MIME profile. This draft will describe
> only the proposed changes to the S/MIME Version 3 Certificate Handling
> RFC [SMIMEV3CERT], and the rest of that RFC will remain identical.


Did I miss the discussion and consensus on this?

I was under the impression that RSA does not replace DSA as a
MUST-implement, rather RSA becomes an additional MUST for signatures:


> Russ Housley <[e-mail]> on 07/31/2000 05:04:52 PM
>
> Proposed way forward:  Change the mandatory to implement algorithm set to:
>      One-way Hash:  SHA-1 (no change)
>      Signature:     Both DSA and RSA (PKCS#1 v1.5)
>      Key Mgmt: RSA (OAEP)
>      Eencryption:   Triple-DES in CBC mode


The Certificate Profile should reflect the results of the last meeting
and subsequent mail list discussion.





Received: by ns.secondary.com (8.9.3/8.9.3) id OAA04119 for ietf-smime-bks; Mon, 27 Nov 2000 14:02:26 -0800 (PST)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04115 for <[e-mail]>; Mon, 27 Nov 2000 14:02:25 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id OAA23359; Mon, 27 Nov 2000 14:03:13 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 27 Nov 2000 16:46:08 -0500
To: "David P. Kemp" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-smime-v31cert-00.txt
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave:

You did not miss anything.  This is a proposed change.  The Working Group 
has not agreed or rejected the proposal.

Russ

At 03:49 PM 11/27/2000 -0500, David P. Kemp wrote:

> >       Title           : S/MIME Version 3.1 Certificate Profile Addendum
> >       Author(s)       : B. Ramsdell
> >       Filename        : draft-ietf-smime-v31cert-00.txt
> >       Pages           :
> >       Date            : 22-Nov-00
> >
> > In light of the expiration of the primary RSA patent, it is proposed
> > that the RSA algorithm replace the DSS and Diffie-Hellman as the MUST
> > implement algorithms in the S/MIME profile. This draft will describe
> > only the proposed changes to the S/MIME Version 3 Certificate Handling
> > RFC [SMIMEV3CERT], and the rest of that RFC will remain identical.
>
>
>Did I miss the discussion and consensus on this?
>
>I was under the impression that RSA does not replace DSA as a
>MUST-implement, rather RSA becomes an additional MUST for signatures:
>
>
> > Russ Housley <[e-mail]> on 07/31/2000 05:04:52 PM
> >
> > Proposed way forward:  Change the mandatory to implement algorithm set to:
> >      One-way Hash:  SHA-1 (no change)
> >      Signature:     Both DSA and RSA (PKCS#1 v1.5)
> >      Key Mgmt: RSA (OAEP)
> >      Eencryption:   Triple-DES in CBC mode
>
>
>The Certificate Profile should reflect the results of the last meeting
>and subsequent mail list discussion.



Received: by ns.secondary.com (8.9.3/8.9.3) id OAA04067 for ietf-smime-bks; Mon, 27 Nov 2000 14:01:23 -0800 (PST)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA04063 for <[e-mail]>; Mon, 27 Nov 2000 14:01:21 -0800 (PST)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.6)); Mon, 27 Nov 2000 14:02:13 -0800
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2650.21) id <XJ563YCT>; Mon, 27 Nov 2000 14:02:13 -0800
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>, [e-mail]
Subject: RE: I-D ACTION:draft-ietf-smime-v31cert-00.txt
Date: Mon, 27 Nov 2000 14:02:06 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 163C066F27524-01-01
Content-Type: text/plain;  charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree, and I screwed up.  Basically I just took the -ramsdell draft and
made it -smime, and I forgot to change the language.

The msg draft didn't get submitted, as I submitted the -ramsdell version
instead of the -smime version.  I think the wording is fixed in there, and
you can certainly point out anything that I missed.  I will send it to the
list soon.

Blake

-----Original Message-----
From: David P. Kemp [mailto:[e-mail]]
Sent: Monday, November 27, 2000 12:49 PM
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-smime-v31cert-00.txt



> 	Title		: S/MIME Version 3.1 Certificate Profile Addendum
> 	Author(s)	: B. Ramsdell
> 	Filename	: draft-ietf-smime-v31cert-00.txt
> 	Pages		: 
> 	Date		: 22-Nov-00
> 	
> In light of the expiration of the primary RSA patent, it is proposed
> that the RSA algorithm replace the DSS and Diffie-Hellman as the MUST
> implement algorithms in the S/MIME profile. This draft will describe
> only the proposed changes to the S/MIME Version 3 Certificate Handling
> RFC [SMIMEV3CERT], and the rest of that RFC will remain identical.


Did I miss the discussion and consensus on this?

I was under the impression that RSA does not replace DSA as a
MUST-implement, rather RSA becomes an additional MUST for signatures:


> Russ Housley <[e-mail]> on 07/31/2000 05:04:52 PM
>
> Proposed way forward:  Change the mandatory to implement algorithm set to:
>      One-way Hash:  SHA-1 (no change)
>      Signature:     Both DSA and RSA (PKCS#1 v1.5)
>      Key Mgmt: RSA (OAEP)
>      Eencryption:   Triple-DES in CBC mode


The Certificate Profile should reflect the results of the last meeting
and subsequent mail list discussion.





Received: by ns.secondary.com (8.9.3/8.9.3) id MAA01479 for ietf-smime-bks; Mon, 27 Nov 2000 12:56:07 -0800 (PST)
Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA01473 for <[e-mail]>; Mon, 27 Nov 2000 12:56:05 -0800 (PST)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id PAA20766 for <[e-mail]>; Mon, 27 Nov 2000 15:32:56 -0500 (EST)
Message-Id: <[e-mail]>
Date: Mon, 27 Nov 2000 15:49:24 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-smime-v31cert-00.txt
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: SqyP0BetNrZE6qqnZjCF7A==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 	Title		: S/MIME Version 3.1 Certificate Profile Addendum
> 	Author(s)	: B. Ramsdell
> 	Filename	: draft-ietf-smime-v31cert-00.txt
> 	Pages		: 
> 	Date		: 22-Nov-00
> 	
> In light of the expiration of the primary RSA patent, it is proposed
> that the RSA algorithm replace the DSS and Diffie-Hellman as the MUST
> implement algorithms in the S/MIME profile. This draft will describe
> only the proposed changes to the S/MIME Version 3 Certificate Handling
> RFC [SMIMEV3CERT], and the rest of that RFC will remain identical.


Did I miss the discussion and consensus on this?

I was under the impression that RSA does not replace DSA as a
MUST-implement, rather RSA becomes an additional MUST for signatures:


> Russ Housley <[e-mail]> on 07/31/2000 05:04:52 PM
>
> Proposed way forward:  Change the mandatory to implement algorithm set to:
>      One-way Hash:  SHA-1 (no change)
>      Signature:     Both DSA and RSA (PKCS#1 v1.5)
>      Key Mgmt: RSA (OAEP)
>      Eencryption:   Triple-DES in CBC mode


The Certificate Profile should reflect the results of the last meeting
and subsequent mail list discussion.




Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA24096 for ietf-smime-bks; Mon, 27 Nov 2000 11:10:15 -0800 (PST)
Received: from public.szptt.net.cn (mail1-smtp.szptt.net.cn [202.96.136.221]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA24090 for <[e-mail]>; Mon, 27 Nov 2000 11:10:12 -0800 (PST)
From: [e-mail]
Received: from public.szptt.net.cn([202.96.136.221]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm43a22e449; Mon, 27 Nov 2000 19:09:31 -0000
Received: from loki.ietf.org([132.151.1.177]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm113a1f8958; Sat, 25 Nov 2000 05:07:48 -0000
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id XAA14999 for [e-mail]; Fri, 24 Nov 2000 23:45:00 -0500 (EST)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id SAA12465 for <[e-mail]>; Fri, 24 Nov 2000 18:28:19 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26413; Fri, 24 Nov 2000 18:28:15 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-v31cert-00.txt
Date: Fri, 24 Nov 2000 18:28:15 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: S/MIME Version 3.1 Certificate Profile Addendum
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-v31cert-00.txt
	Pages		: 
	Date		: 22-Nov-00
	
In light of the expiration of the primary RSA patent, it is proposed
that the RSA algorithm replace the DSS and Diffie-Hellman as the MUST
implement algorithms in the S/MIME profile. This draft will describe
only the proposed changes to the S/MIME Version 3 Certificate Handling
RFC [SMIMEV3CERT], and the rest of that RFC will remain identical.

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

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


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-v31cert-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="[e-mail]"

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

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

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

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

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id PAA20132 for ietf-smime-bks; Fri, 24 Nov 2000 15:27:15 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20128 for <[e-mail]>; Fri, 24 Nov 2000 15:27:13 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26425; Fri, 24 Nov 2000 18:28:18 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-aes-alg-00.txt
Date: Fri, 24 Nov 2000 18:28:18 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Use of the Advanced Encryption Algorithm in CMS
	Author(s)	: J. Schaad
	Filename	: draft-ietf-smime-aes-alg-00.txt
	Pages		: 6
	Date		: 22-Nov-00
	
This document specifies how to incorporate the Advanced Encryption
Standard (AES) candidate algorithm [AES] 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 the AES algorithms may be included in the CMS
specification [CMS] for symmetric content and key encryption.

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

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


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-aes-alg-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="[e-mail]"

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

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

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

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

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id PAA20126 for ietf-smime-bks; Fri, 24 Nov 2000 15:27:12 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20121 for <[e-mail]>; Fri, 24 Nov 2000 15:27:11 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26413; Fri, 24 Nov 2000 18:28:15 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-v31cert-00.txt
Date: Fri, 24 Nov 2000 18:28:15 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: S/MIME Version 3.1 Certificate Profile Addendum
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-v31cert-00.txt
	Pages		: 
	Date		: 22-Nov-00
	
In light of the expiration of the primary RSA patent, it is proposed
that the RSA algorithm replace the DSS and Diffie-Hellman as the MUST
implement algorithms in the S/MIME profile. This draft will describe
only the proposed changes to the S/MIME Version 3 Certificate Handling
RFC [SMIMEV3CERT], and the rest of that RFC will remain identical.

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

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


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-v31cert-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="[e-mail]"

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

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

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA20117 for ietf-smime-bks; Fri, 24 Nov 2000 15:27:09 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20113 for <[e-mail]>; Fri, 24 Nov 2000 15:27:08 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26403; Fri, 24 Nov 2000 18:28:12 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-domsec-07.txt
Date: Fri, 24 Nov 2000 18:28:12 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Domain Security Services using S/MIME
	Author(s)	: T. Dean, W. Ottaway
	Filename	: draft-ietf-smime-domsec-07.txt
	Pages		: 8
	Date		: 22-Nov-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 series and SMTP/MIME, or when a
single domain wishes to communicate securely with one of its members
residing on an untrusted domain. The scenarios covered by this document
are domain to domain, individual to domain and domain to individual
communications. 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-07.txt

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-domsec-07.txt

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

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

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id QAA07941 for ietf-smime-bks; Wed, 22 Nov 2000 16:23:11 -0800 (PST)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA07930 for <[e-mail]>; Wed, 22 Nov 2000 16:23:10 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com (208-58-192-39.s39.tnt9.lnhva.md.dialup.rcn.com [208.58.192.39]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id QAA09287 for <[e-mail]>; Wed, 22 Nov 2000 16:23:33 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 22 Nov 2000 19:03:54 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Draft S/MIME WG Agenda for San Diego
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Please contact me immediately if you would like a time slot and you are not 
on the attached draft agenda.

Russ


   DRAFT    DRAFT    DRAFT    DRAFT    DRAFT    DRAFT

             S/MIME Mail Security WG Agenda
                 San Diego, California
                     December 2000

Introductions                           Russ Housley
Working Group Status                    Russ Housley
Interoperability Matrix                 Jim Schaad
Security Policies and Labels            (Weston Nicolls)
Symmetric Key Distribution              Sean Turner
Domain Security (DOMSEC)                Bill Ottaway
Reuse of Content Encryption Keys        Steve Farrell
Advanced Encryption Standard (AES)      Jim Schaad
RSA as a MUST implement         Blake Ramsdell
S/MIME Freeware Library [*]             John Pawling
Wrap up                                 Russ Housley


( ) Author cannot attend; proxy will lead discussion
[*] If time permits



Received: by ns.secondary.com (8.9.3/8.9.3) id IAA17017 for ietf-smime-bks; Wed, 22 Nov 2000 08:38:30 -0800 (PST)
Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17013 for <[e-mail]>; Wed, 22 Nov 2000 08:38:28 -0800 (PST)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <WY8BZWRM>; Wed, 22 Nov 2000 11:38:55 -0500
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "'Ahmed Bhamjee'" <[e-mail]>, [e-mail]
Subject: RE: S/MIME v3 implementations
Date: Wed, 22 Nov 2000 11:38:56 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ahmed,

The S/MIME Freeware Library (SFL) uses the freeware Crypto++ library to
implement RFC 2631.  We have performed successful RFC 2631 interoperability
testing between the SFL and the Microsoft Outlook 2000 S/MIME v3
implementation.  Also, the SFL has been used to perform RFC 2631
interoperability testing with Baltimore Technologies S/MIME v3
implementation.

When using E-S D-H, the originator uses the recipient's D-H public key
parameters to generate the originator's ephemeral D-H private/public key
pair.  If you are sending the same message to multiple recipients who have
different D-H key sizes, then the originator can generate a unique ephemeral
D-H private/public key pair for each different recipient key size.  In this
case, the originator would include a separate RecipientInfo in the
EnvelopedData for each different recipient key size.

Please let me know if you require further information regarding the SFL or
the interoperability testing that we have conducted.

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================

-----Original Message-----
From: Ahmed Bhamjee [mailto:[e-mail]]
Sent: Wednesday, November 22, 2000 5:36 AM
To: [e-mail]
Subject: S/MIME v3 implementations


Could someone please provide me (or point me to a location where I can find)
a list of products which implement Diffie-Hellman as per RFC 2631.

Also, when using Diffie-Hellman Ephemeral-Static mode, what key size do you
use to generate a new key pair. You could use the key size of the recipient,
but what if you are sending the same message to multiple recipients who may
have different DH key sizes. Another option is to use the size of your own
static DH key pair.

I would appreciate any advice or help with this.

Thanks in advance
Ahmed


Received: by ns.secondary.com (8.9.3/8.9.3) id IAA15393 for ietf-smime-bks; Wed, 22 Nov 2000 08:11:44 -0800 (PST)
Received: from thehub.knight-hub.com (thehub.knight-hub.com [205.177.16.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15388 for <[e-mail]>; Wed, 22 Nov 2000 08:11:42 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com (va.spyrus.com [205.177.169.194]) by thehub.knight-hub.com (8.9.3/8.9.3) with ESMTP id LAA18074; Wed, 22 Nov 2000 11:07:01 -0500
Posted-Date: Wed, 22 Nov 2000 11:07:01 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 22 Nov 2000 11:02:36 -0500
To: "Ahmed Bhamjee" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: S/MIME v3 implementations
Cc: <[e-mail]>
In-Reply-To: <000001c0546f$f170f9f0$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

You need to take a closer look at RFC 2630 and RFC 2631.  You might need to 
generate a different ephemeral key for each recipient.  You can use the 
same one for multiple recipients if and only if they have the same p, q, 
and g domain parameter values.  The originator must use the recipient 
domain parameters when generating the ephemeral key pair.

Russ


At 10:35 AM 11/22/2000 +0000, Ahmed Bhamjee wrote:
>Could someone please provide me (or point me to a location where I can find)
>a list of products which implement Diffie-Hellman as per RFC 2631.
>
>Also, when using Diffie-Hellman Ephemeral-Static mode, what key size do you
>use to generate a new key pair. You could use the key size of the recipient,
>but what if you are sending the same message to multiple recipients who may
>have different DH key sizes. Another option is to use the size of your own
>static DH key pair.
>
>I would appreciate any advice or help with this.
>
>Thanks in advance
>Ahmed



Received: by ns.secondary.com (8.9.3/8.9.3) id CAA17558 for ietf-smime-bks; Wed, 22 Nov 2000 02:36:07 -0800 (PST)
Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA17539 for <[e-mail]>; Wed, 22 Nov 2000 02:36:03 -0800 (PST)
Received: from mail0.sse.ie (actually localhost) by mail0.sse.ie; Wed, 22 Nov 2000 10:38:38 +0000
Received: from ahmed (ahmed.sse.ie [193.120.32.196]) by mail0.sse.ie (8.9.1a/8.9.1) with SMTP id KAA22948 for <[e-mail]>; Wed, 22 Nov 2000 10:38:36 GMT
From: "Ahmed Bhamjee" <[e-mail]>
To: <[e-mail]>
Subject: S/MIME v3 implementations
Date: Wed, 22 Nov 2000 10:35:32 -0000
Message-ID: <000001c0546f$f170f9f0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Disposition-Notification-To: "Ahmed Bhamjee" <[e-mail]>
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Could someone please provide me (or point me to a location where I can find)
a list of products which implement Diffie-Hellman as per RFC 2631.

Also, when using Diffie-Hellman Ephemeral-Static mode, what key size do you
use to generate a new key pair. You could use the key size of the recipient,
but what if you are sending the same message to multiple recipients who may
have different DH key sizes. Another option is to use the size of your own
static DH key pair.

I would appreciate any advice or help with this.

Thanks in advance
Ahmed



Received: by ns.secondary.com (8.9.3/8.9.3) id HAA14950 for ietf-smime-bks; Tue, 21 Nov 2000 07:09:48 -0800 (PST)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA14946 for <[e-mail]>; Tue, 21 Nov 2000 07:09:46 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id HAA15177 for <[e-mail]>; Tue, 21 Nov 2000 07:10:05 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 21 Nov 2000 10:10:05 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: S/MIME WG Agenda
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Our tentative meeting slot for the upcoming meeting in San Diego was just 
announced.

WEDNESDAY, 13 December 2000 from 1530 to 1730

   SEC  smime     S/MIME Mail Security WG
   APP  webdav    WWW Distributed Authoring and Versioning WG
   INT  frnetmib  Frame Relay Service MIB WG
   OPS  sls       Service Level Specification and Usage BOF
   OPS  sming     Next Generation Structure of Man agement Information BOF
   RTG  idr       Internet-Domain Routing WG
   TSV  avt       Audio/Video Transport WG
   TSV  seamoby   SeaMoby BOF

I will be posting a proposed agenda for the two hours soon.

Russ



Received: by ns.secondary.com (8.9.3/8.9.3) id PAA00577 for ietf-smime-bks; Sun, 19 Nov 2000 15:05:16 -0800 (PST)
Received: from unknown ([198.211.237.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA00573; Sun, 19 Nov 2000 15:05:13 -0800 (PST)
From: [e-mail]
Subject: toner cartridges
Date: Wed, 19 Nov 1997 14:28:02
Message-Id: <400.389117.88183@>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Toner Supplies at discount prices
Laser Printer Toner Cartridges 
Fax and Copier Cartridges

Order by phone:[phone]
Order by fax: [phone]

*** E-mail removal line: 1-888-248-4930 ***

*** If you would like to mail your order please call 
1-888-248-2015 ***


Pay by check, credit card or Purchase Order.

If your order is by check please leave your check number (Mail 
check when you recieve merchandise)
If your order is by credit card please leave your card number + 
expiration date
If your order is by P.O. please leave your shipping/billing 
addresses


Current Prices are as follows:  
                                
Cartridges for Hewlett Packard printers:    
                                
4L,4p,1100 and series 2 cartridges are now $49 
2p cartridges are $54            
3si cartridges are $75           
4000 and 2100 cartridges are $79 
5000 and 8100 cartridges are $135
5p, 6p, 5mp and 6mp cartridges are $59

Cartridges for Apple printers

Pro 600 or 16-600 cartridges are now $69 
Laser writer select 300,320 and 360 cartridges are $69
Laser writer 300 and 320 cartridges are $54
Laser writer NT, 2nt, 2f, 2g and LS cartridges are $54
Laser writer personal 12-640 cartridges are $79

Cartridges for Hewlett Packard laser fax printers:

Laser fax 500,700,5000,7000,fx1 and fx2 cartridges are now $59
Laser fax fx3 cartridges are $69
Our laser fax fx4 cartridges are $79

Cartridges for Lexmark and IBM printers

Optra 4019 and 4029 are now $125
optra r,r+ and optra s cartridges are $135
optra e cartridges are $59

Our cartridges for canon copiers

PC 3, 6re, 7 and 11 (A30) are now $69
PC 300,320,700,720 and 760 (E-40) are $89

90 day extended warranty included on all products.

 
 
 
 
 


Received: by ns.secondary.com (8.9.3/8.9.3) id CAA17511 for ietf-smime-bks; Sat, 18 Nov 2000 02:14:37 -0800 (PST)
Received: from starlink.co.kr ([203.242.202.130]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA17493 for <[e-mail]>; Sat, 18 Nov 2000 02:14:34 -0800 (PST)
Message-Id: <[e-mail]>
Received: from [38.26.242.229] by starlink.co.kr (SMTPD32-3.04) id A8086740220; Sat, 18 Nov 2000 19:20:56 +0900
From: "Edward Kopen" <[e-mail]>
Subject: Get rid of your "LOVE HANDLES' in 24 hours... # 1A0
To: nop20xc
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3
Mime-Version: 1.0
Date: Fri, 17 Nov 2000 21:58:36 -0500
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA17499
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

JUST IN TIME FOR THE HOLIDAYS!!!!!!

It only takes an hour of your time
to gently rub in our miracle gel and
.. LOSE 4-6 INCHES OF STUBBORN FAT OVERNIGHT!

****FLATTEN your stomach.
****RE-SHAPE your butt.
****TRIM your thighs.
****REDUCE cellulite everywhere!


^^^WITHOUT strict diets
^^^WITHOUT strenuous exercise
^^^WITHOUT harmful metabolism boosters
^^^WITHOUT expensive surgery


Do you want to...

[   ]  GET SLIM for the Holidays & STAY SLIM?

[   ]  EAT WHAT YOU WANT at Holiday feasts and
        festivities but GET RID OF those extra  inches FAST?

[   ]  BEGIN THE NEW YEAR without having to
        go on ANOTHER DIET?


YOU CAN DO IT ALL!!!!!
with the safe and reliable overnight results of
our MIRACLE GEL.
It's safe to use as often as once a week
to help you lose more and more inches
OR...
to lose the added inches
of too much Holiday celebrating!


            GUARANTEED RESULTS!

"My wife was scheduled for $6,000 liposuction surgery.
We saw your ad and decided your product was worth
trying first. Words can't express our delight!   My wife
lost four inches in her midriff and three inches in her waist,
much more than the 'average results' in your ad. Needless
to say, we cancelled the surgery."
                                            Eric Larsen, Lacrosse, WI

"I'm a professional singer, and I'm on the road a lot.  I lost
almost two inches in my waistline in the first 24 hours.
I am very proud of the fact that I have lost this waistline
and obliques fat."
                                            David Hutchins, Hickory,
NC

"I lost one inch in my waist, one inch in my hips, and two inches
in my thighs. The overnight results with your product are
really great!  Thank you!"
                                            Susan Meir, New York, NY


FOR MORE FREE INFORMATION, lots of testimonials, and
a step-by-step description of how this product safely creates
such amazing overnight results 

Reply To:  
mailto:[e-mail]?subject=more_info

CALL US: 520-203-4572 (9am-6pm, MST Mon-Sun)
You'll talk to people who have used our miracle gels.

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






Received: by ns.secondary.com (8.9.3/8.9.3) id HAA25303 for ietf-smime-bks; Thu, 16 Nov 2000 07:56:38 -0800 (PST)
Received: from swordfish.nexor.co.uk (swordfish.nexor.co.uk [193.63.53.54]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA25276 for <[e-mail]>; Thu, 16 Nov 2000 07:56:33 -0800 (PST)
Received: by swordfish.nexor.co.uk with Internet Mail Service (5.5.2650.14) id <WRY8AW78>; Thu, 16 Nov 2000 16:03:58 -0000
Message-ID: <[e-mail]>
From: Graeme Lunt <[e-mail]>
To: "'Bonatti, Chris'" <[e-mail]>
Cc: [e-mail], "'[e-mail]'" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-x400transport-00.txt
Date: Thu, 16 Nov 2000 16:03:49 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.14)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Graeme,
> 
> I think that 'id-data' covers any MIME object, not just 
> CMS.  Since it's defined in the S/MIME standards, the door 
> is certainly open for somebody to question the scope of its 
> use as a generally applicable identifier for all
> MIME.  However, since (to my knowledge) nothing like this 
> exists elsewhere, it's the best choice available.
 
OK - that's good - that's clarified it for me. 

I'm not sure if this could be commented on in the draft, maybe 
in the context of carrying multipart/signed? 

If so, something like:

"If a multipart/signed message is to be transported in X.400, the
CMS-defined
value id-data SHOULD be used in the content-type field of the P1 envelope."

after the definition of id-data in section 2.2?

However, you may not want to do this if the draft is just looking
at transporting CMS objects, or do want start down the road of 
addressing transporting generic MIME in this draft.

Graeme



Received: by ns.secondary.com (8.9.3/8.9.3) id GAA26998 for ietf-smime-bks; Thu, 16 Nov 2000 06:36:46 -0800 (PST)
Received: from smtp-a.capu.net (IDENT:[e-mail] [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA26989 for <[e-mail]>; Thu, 16 Nov 2000 06:36:44 -0800 (PST)
Received: from ieca.com (mva-aa-005.capu.net [207.226.159.5]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id JAA19636; Thu, 16 Nov 2000 09:44:11 -0500
Message-ID: <[e-mail]>
Date: Thu, 16 Nov 2000 09:44:06 -0500
From: "Bonatti, Chris" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Graeme Lunt <[e-mail]>
CC: "'Russ Housley'" <[e-mail]>, [e-mail], "'[e-mail]'" <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-smime-x400transport-00.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Graeme Lunt wrote:

> In fact, thinking about it a little more, does the draft as it stands
> actually allow me to do this? If I use id-data as the content-type,
> MUST the content be a MIME wrapped CMS object? Could it just be arbitrary
> MIME?
>
> This would certainly be a useful feature.
>

Graeme,

    I think that 'id-data' covers any MIME object, not just CMS.  Since it's
defined in the S/MIME standards, the door is certainly open for somebody to
question the scope of its use as a generally applicable identifier for all
MIME.  However, since (to my knowledge) nothing like this exists elsewhere,
it's the best choice available.

Chris





Received: by ns.secondary.com (8.9.3/8.9.3) id GAA25989 for ietf-smime-bks; Thu, 16 Nov 2000 06:32:38 -0800 (PST)
Received: from smtp-a.capu.net (IDENT:[e-mail] [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA25980 for <[e-mail]>; Thu, 16 Nov 2000 06:32:35 -0800 (PST)
Received: from ieca.com (mva-aa-124.capu.net [207.226.159.124]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id JAA19248; Thu, 16 Nov 2000 09:40:02 -0500
Message-ID: <[e-mail]>
Date: Thu, 16 Nov 2000 09:39:57 -0500
From: "Bonatti, Chris" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Graeme Lunt <[e-mail]>
CC: [e-mail], "'[e-mail]'" <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-smime-x400wrap-00.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Graeme Lunt wrote:

> Maybe a better wording is to say that:
>
> "this X.400 content SHOULD maintain the encoding defined by the
> content type"
>
> rather than implying that an ASN.1 encoding should be used if
> possible?
>

Okay, that makes good sense.

Chris





Received: by ns.secondary.com (8.9.3/8.9.3) id DAA27317 for ietf-smime-bks; Thu, 16 Nov 2000 03:20:59 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA27296 for <[e-mail]>; Thu, 16 Nov 2000 03:20:46 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09214; Thu, 16 Nov 2000 06:28:19 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-cms-rsaes-oaep-02.txt
Date: Thu, 16 Nov 2000 06:28:19 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id CAA15263 for ietf-smime-bks; Thu, 16 Nov 2000 02:45:45 -0800 (PST)
Received: from swordfish.nexor.co.uk (swordfish.nexor.co.uk [193.63.53.54]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA15252 for <[e-mail]>; Thu, 16 Nov 2000 02:45:43 -0800 (PST)
Received: by swordfish.nexor.co.uk with Internet Mail Service (5.5.2650.14) id <WRY8AWZV>; Thu, 16 Nov 2000 10:53:01 -0000
Message-ID: <[e-mail]>
From: Graeme Lunt <[e-mail]>
To: "'Bonatti, Chris'" <[e-mail]>
Cc: [e-mail], "'[e-mail]'" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-x400wrap-00.txt
Date: Thu, 16 Nov 2000 10:53:00 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.14)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chris,

> I'm going to have to check up on your other comments, but 
> this one has an immediate answer.  The reason that the ASN.1 
> encoding is a SHOULD and not a MUST is that X.400 allows 
> non-ASN.1 content.  

Fair point!

Maybe a better wording is to say that:

"this X.400 content SHOULD maintain the encoding defined by the 
content type" 

rather than implying that an ASN.1 encoding should be used if 
possible?

Graeme


Received: by ns.secondary.com (8.9.3/8.9.3) id CAA11893 for ietf-smime-bks; Thu, 16 Nov 2000 02:34:38 -0800 (PST)
Received: from swordfish.nexor.co.uk (swordfish.nexor.co.uk [193.63.53.54]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA11869 for <[e-mail]>; Thu, 16 Nov 2000 02:34:34 -0800 (PST)
Received: by swordfish.nexor.co.uk with Internet Mail Service (5.5.2650.14) id <WRY8AWZS>; Thu, 16 Nov 2000 10:41:51 -0000
Message-ID: <[e-mail]>
From: Graeme Lunt <[e-mail]>
To: "'Russ Housley'" <[e-mail]>
Cc: [e-mail], "'[e-mail]'" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-x400transport-00.txt
Date: Thu, 16 Nov 2000 10:41:46 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.14)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

> The CMS contentInfo uses id-data when the content is expected to be 
> MIME.  This choice is for historical reasons (S/MIME v2 did 
> it that way).
> 
> I think that the authors are trying to avoid a layer of MIME 
> encapsulation.  

Yes - I can see that you would want to avoid this.

> Did I miss something?

My comment was a little different. 

What is being proposed is that the OID id-data must be used for the
X.400 content type when the CMS object is covered by an outer MIME 
wrapper. 

However, a more generic option is to use an OID (say "id-mime") for 
the X.400 content type that represents MIME. 
Using this content type I could still carry my MIME wrapped CMS object, 
but I could also carry other arbitray MIME objects. For example, I 
could carry multipart/signed with this method.

In fact, thinking about it a little more, does the draft as it stands
actually allow me to do this? If I use id-data as the content-type, 
MUST the content be a MIME wrapped CMS object? Could it just be arbitrary
MIME?

This would certainly be a useful feature.

Graeme


Received: by ns.secondary.com (8.9.3/8.9.3) id DAA11474 for ietf-smime-bks; Tue, 14 Nov 2000 03:37:35 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA11470 for <[e-mail]>; Tue, 14 Nov 2000 03:37:33 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09951; Tue, 14 Nov 2000 06:44:58 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-idea-08.txt
Date: Tue, 14 Nov 2000 06:44:58 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

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

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA09641 for ietf-smime-bks; Tue, 14 Nov 2000 03:12:13 -0800 (PST)
Received: from post.ffi.no (post.ffi.no [193.156.99.133]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA09626; Tue, 14 Nov 2000 03:12:03 -0800 (PST)
Received: by post.ffi.no with Internet Mail Service (5.5.2650.21) id <40130J4A>; Tue, 14 Nov 2000 12:19:15 +0100
Message-ID: <[e-mail]>
From: Anders Eggen <[e-mail]>
To: "'Graeme Lunt'" <[e-mail]>, [e-mail]
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: SV: I-D ACTION:draft-ietf-smime-x400wrap-00.txt
Date: Tue, 14 Nov 2000 12:19:06 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04E2C.B8FAF65A"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

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

Graeme,

>Here are some comments on the following draft:
> 	Title		: Securing X.400 Content with S/MIME
>They relate to section 3.2.
>
>The use of the terms "signedData Element", "signedData object" and 
>"signedData structure" seems a little confusing. As I read it:
>
>"signedData element" is the encapContentInfo(EncapsulatedContentInfo) 
>field within "SignedData"
>
>"signedData structure" is the complete SignedData SEQUENCE
>
>and
>
>"signedData object" is the the ContentInfo SEQUENCE, with a
>contentType of id-signedData, containing the SignedData SEQUENCE
>
>If this is indeed correct, then the last sentence of para 2. should 
>be made the first sentence of para 1. This would more closely follow
>the line of processing, and indicate the use of only one optional 
>MIME encoding, the transport.

>Which raises .............

	A similar set of comments apply to section 3.3

	Graeme


I understand that this may seem a little confusing. To make this clearer
throughout the chapter, I propose that we do the following (underlined)
changes:


*	The first paragraph of section 3.2 should be:
	"The SignedData format as described in the ......"

*	The second paragraph of section 3.2 should be:
	"The protected X.400 content MUST then be placed in the SignedData
encapContentInfo eContent field. Note that this X.400 content SHOULD be
ASN.1 encoded, but SHOULD NOT be MIME wrapped. The object identifier for the
content type of the protected X.400 content MUST be placed in the SignedData
encapContentInfo eContentType field.  The resulting signedData object MAY
optionally be wrapped in a MIME encoding."

*	The third paragraph of section 3.2 should be:
	"The signedData object is encapsulated by a ........"

*	The step 2 in section 3.2.1. shoul be:
	"Step 2. The ASN.1 encoded X.400 content and other required data is
	processed into a CMS object of type SignedData."

*	The second paragraph of section 3.3 should be:
	"The EnvelopedData format as described in the............." 

*	The third paragraph of section 3.3 should be:
	"The protected X.400 content MUST be placed in the EnvelopedData
encryptedContentInfo encryptedContent field. Note that this X.400 content
should be ASN.1 encoded, but should not be MIME wrapped. The object
identifier for content type of the protected X.400 content MUST be placed in
the EnvelopedData encryptedContentInfo contentType field. The resulting
envelopedData object MAY optionally be wrapped in a MIME encoding.

*	The fouth paragraph of section 3.3 should be:
	"The envelopedData object is encapsulated by ......."

*	The first sentence of step 2 in section 3.3.1 shoul be:
	"The ASN.1 encoded X.400 content and other required data is
processed into a CMS object of type EnvelopedData.

*	The steps of the tripple wrapping in section 3.4.1 should be written
as; step 1, step 2 ..., and not just marked with numbers.

*	The first sentence of step 2 in section 3.4.1 shoul be:
	"Step 2. Place the protected ASN.1 encoded X.400 content in the
SignedData encapContentInfo eContent field.



Anders Eggen





> -----Opprinnelig melding-----
> Fra:	Graeme Lunt [SMTP:[e-mail]]
> Sendt:	Friday, November 10, 2000 9:31 AM
> Til:	[e-mail]
> Kopi:	'[e-mail]'
> Emne:	RE: I-D ACTION:draft-ietf-smime-x400wrap-00.txt
> 
> Hi,
> 
> Here are some comments on the following draft:
> > 	Title		: Securing X.400 Content with S/MIME
> 
> They relate to section 3.2.
> 
> The use of the terms "signedData Element", "signedData object" and 
> "signedData structure" seems a little confusing. As I read it:
> 
> "signedData element" is the encapContentInfo(EncapsulatedContentInfo) 
> field within "SignedData"
> 
> "signedData structure" is the complete SignedData SEQUENCE
> 
> and
> 
> "signedData object" is the the ContentInfo SEQUENCE, with a
> contentType of id-signedData, containing the SignedData SEQUENCE
> 
> If this is indeed correct, then the last sentence of para 2. should 
> be made the first sentence of para 1. This would more closely follow
> the line of processing, and indicate the use of only one optional 
> MIME encoding, the transport.
> 
> Which raises another other point. In para 2, it states that:
> "X.400 content SHOULD be ASN.1 encoded" (and consequently MUST NOT be
> MIME wrapped). Surely this should be "MUST be ASN.1 encoded", 
> especially given that the "content type of the protected X.400 content
> MUST be placed in the eContentType field". (The use of "SHOULD" is 
> also somewhat at variance with step 1 in 3.4.1 which mandates ASN.1
> encoding for triple-wrapped messages).
> 
> For example, if I find an eContentType of "2.6.1.10.1" (P22), I would
> expect the content to be ASN.1 encoded.
> Is there a reason why you would want to allow a different encoding of
> the X.400 content prior to protection, or is this just a typo?
> 
> (In para 2, 3rd sentence you should add a "the", so as to read:
> "The object identifier for the content type ...")
> 
> A similar set of comments apply to section 3.3
> 
> Graeme

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>SV: I-D ACTION:draft-ietf-smime-x400wrap-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Graeme,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">Here are some comments on the following draft:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Title&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Securing =
X.400 Content with S/MIME</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">They relate to section 3.2.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">The use of the terms &quot;signedData Element&quot;, =
&quot;signedData object&quot; and </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">&quot;signedData structure&quot; seems a little =
confusing. As I read it:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">&quot;signedData element&quot; is the =
encapContentInfo(EncapsulatedContentInfo) </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">field within &quot;SignedData&quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">&quot;signedData structure&quot; is the complete =
SignedData SEQUENCE</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">&quot;signedData object&quot; is the the ContentInfo =
SEQUENCE, with a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">contentType of id-signedData, containing the SignedData =
SEQUENCE</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">If this is indeed correct, then the last sentence of =
para 2. should </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">be made the first sentence of para 1. This would more =
closely follow</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">the line of processing, and indicate the use of only one =
optional </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">MIME encoding, the transport.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">Which raises</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">.............</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">A similar set of comments apply to =
section 3.3</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Graeme</FONT>
</P>
<BR>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I understand that =
this may seem a little confusing. To make this clearer throughout the =
chapter, I propose that we do the following (underlined) =
changes:</FONT></P>
<BR>

<UL><LI><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">The first =
paragraph of section 3.2 should be:</FONT></LI>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&quot;The<U> =
S</U>ignedData format as described in the ......&quot;</FONT>
</P>
<LI><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">The second =
paragraph of section 3.2 should be:</FONT></LI>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&quot;The protected =
X.400 content MUST then be placed in the</FONT><U> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">SignedData e</FONT><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">ncapContentInfo</FONT><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"> eContent =
field</FONT></U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">. Note =
that this X.400 content SHOULD be ASN.1 encoded, but SHOULD NOT be MIME =
wrapped. The object identifier for the content type of the protected =
X.400 content MUST be placed in the</FONT><U> <FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial">SignedData e</FONT><FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial">ncapContentInfo</FONT><FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial"> eContentType field</FONT></U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">.&nbsp; The resulting =
signedData</FONT><U> <FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">object</FONT></U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"> MAY optionally be wrapped in a MIME =
encoding.&quot;</FONT></P>
<LI><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">The third paragraph =
of section 3.2 should be:</FONT></LI>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&quot;The =
signedData</FONT><U> <FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">object</FONT></U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"> is encapsulated by a ........&quot;</FONT>
</P>
<LI><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">The step 2 in =
section 3.2.1. shoul be:</FONT></LI>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&quot;Step 2. The =
ASN.1 encoded X.400 content and other required data is</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">processed into a =
CMS object of type</FONT><U> <FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">S</FONT></U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">ignedData.&quot;</FONT>
</P>
<LI><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">The second =
paragraph of section 3.3 should be:</FONT></LI>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&quot;The</FONT><U> =
<FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">E</FONT></U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">nvelopedData format as =
described in the.............&quot; </FONT>
</P>
<LI><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">The third paragraph =
of section 3.3 should be:</FONT></LI>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&quot;The protected =
X.400 content MUST be placed in the</FONT><U> <FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial">EnvelopedData encryptedContentInfo =
encryptedContent field</FONT></U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">. Note that this X.400 content should be ASN.1 encoded, =
but should not be MIME wrapped. The object identifier for content type =
of the protected X.400 content MUST be placed in the</FONT><U> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">EnvelopedData =
encryptedContentInfo contentType field</FONT></U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">. The resulting envelopedData =
object MAY optionally be wrapped in a MIME encoding.</FONT></P>
<LI><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">The fouth paragraph =
of section 3.3 should be:</FONT></LI>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&quot;The =
envelopedData</FONT><U> <FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">object</FONT></U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"> is encapsulated by .......&quot;</FONT>
</P>
<LI><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">The first sentence =
of step 2 in section 3.3.1 shoul be:</FONT></LI>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&quot;The ASN.1 =
encoded X.400 content and other required data is processed into a CMS =
object of type</FONT><U> <FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">E</FONT></U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">nvelopedData.</FONT>
</P>
<LI><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">The steps of the =
tripple wrapping in section 3.4.1 should be written as; step 1, step 2 =
..., and not just marked with numbers.</FONT></LI>
<BR>
<LI><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">The first sentence =
of step 2 in section 3.4.1 shoul be:</FONT></LI>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&quot;</FONT><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">Step 2.</FONT></U> <FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">Place the protected ASN.1 encoded X.400 content in =
the</FONT><U> <FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">SignedData e</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">ncapContentInfo</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"> eContent field</FONT></U><FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial">.</FONT>
</P>
<BR>
<BR>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Anders Eggen</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Opprinnelig melding-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Fra:&nbsp;&nbsp;&nbsp;</FONT></B> =
<FONT SIZE=3D1 FACE=3D"Arial">Graeme Lunt =
[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sendt:&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Friday, November 10, 2000 9:31 AM</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Til:&nbsp;&nbsp;&nbsp;</FONT></B> =
<FONT SIZE=3D1 FACE=3D"Arial">[e-mail]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Kopi:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">'[e-mail]'</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Emne:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">RE: I-D =
ACTION:draft-ietf-smime-x400wrap-00.txt</FONT>
</P>

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

<P><FONT SIZE=3D2 FACE=3D"Arial">Here are some comments on the =
following draft:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Title&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Securing =
X.400 Content with S/MIME</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">They relate to section 3.2.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The use of the terms &quot;signedData =
Element&quot;, &quot;signedData object&quot; and </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;signedData structure&quot; =
seems a little confusing. As I read it:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;signedData element&quot; is the =
encapContentInfo(EncapsulatedContentInfo) </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">field within =
&quot;SignedData&quot;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;signedData structure&quot; is =
the complete SignedData SEQUENCE</FONT>
</P>

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

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;signedData object&quot; is the =
the ContentInfo SEQUENCE, with a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">contentType of id-signedData, =
containing the SignedData SEQUENCE</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">If this is indeed correct, then the =
last sentence of para 2. should </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">be made the first sentence of para 1. =
This would more closely follow</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the line of processing, and indicate =
the use of only one optional </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">MIME encoding, the transport.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Which raises another other point. In =
para 2, it states that:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;X.400 content SHOULD be ASN.1 =
encoded&quot; (and consequently MUST NOT be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">MIME wrapped). Surely this should be =
&quot;MUST be ASN.1 encoded&quot;, </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">especially given that the =
&quot;content type of the protected X.400 content</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">MUST be placed in the eContentType =
field&quot;. (The use of &quot;SHOULD&quot; is </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">also somewhat at variance with step 1 =
in 3.4.1 which mandates ASN.1</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">encoding for triple-wrapped =
messages).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">For example, if I find an eContentType =
of &quot;2.6.1.10.1&quot; (P22), I would</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">expect the content to be ASN.1 =
encoded.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Is there a reason why you would want =
to allow a different encoding of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the X.400 content prior to =
protection, or is this just a typo?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">(In para 2, 3rd sentence you should =
add a &quot;the&quot;, so as to read:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;The object identifier for the =
content type ...&quot;)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">A similar set of comments apply to =
section 3.3</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Graeme</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C04E2C.B8FAF65A--


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA10361 for ietf-smime-bks; Mon, 13 Nov 2000 23:23:28 -0800 (PST)
Received: from alpha.it-sec.com (alpha.it-sec.com [195.141.254.202] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA10341 for <[e-mail]>; Mon, 13 Nov 2000 23:23:24 -0800 (PST)
Received: from svzh0004.itsec.ch (localhost [127.0.0.1]) by alpha.it-sec.com (8.9.3/8.9.3) with ESMTP id IAA14143; Tue, 14 Nov 2000 08:28:20 +0100 (MET)
Received: by SVZH0004 with Internet Mail Service (5.5.2448.0) id <WSGC4BX6>; Tue, 14 Nov 2000 08:29:20 +0100
Message-ID: <F5545CEFBE7CD31190C90004AC4C1B6438966D@SVZH0004>
From: "Teiwes, Stephan (iT_SEC)" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, [e-mail]
Subject: RE: draft-ietf-smime-idea-08.txt
Date: Tue, 14 Nov 2000 08:29:18 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="windows-1252"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi

draft-ietf-smime-idea-08.txt has been modified considering the comments of 
M. Masiutin, RIT Research Labs. 

*Stephan Teiwes, iT_Security AG

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Montag, 13. November 2000 19:50
To: [e-mail]
Subject: draft-ietf-smime-idea-08.txt


All:

I believe that this takes care of all of the issues raised during working 
group Last Call.  Did I miss anything?

Russ

>From: "Teiwes, Stephan (iT_SEC)" <[e-mail]>
>To: "'Maxim Masiutin'" <[e-mail]>,
>         "Teiwes, Stephan (iT_SEC)"
>         <[e-mail]>,
>         "Hartmann, Peter  (iT_SEC)"
>         <[e-mail]>,
>         [e-mail], [e-mail]
>Subject: RE: Use of the IDEA Encryption Algorithm in CMS
>Date: Mon, 23 Oct 2000 16:52:21 +0200
>X-Mailer: Internet Mail Service (5.5.2448.0)
>List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
>List-ID: <ietf-pkix.imc.org>
>List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
>
>Dear Mr. Masuitin,
>
>thanks a lot. We'll consider your comments and try to improve the draft
>accordingly.
>
>*Stephan Teiwes
>iT_Security AG
>www.it-sec.com
>
>-----Original Message-----
>From: Maxim Masiutin [mailto:[e-mail]]
>Sent: Montag, 23. Oktober 2000 16:41
>To: [e-mail]; [e-mail];
>[e-mail]; [e-mail]
>Subject: Use of the IDEA Encryption Algorithm in CMS
>
>
>Dear authors of "Use of the IDEA Encryption Algorithm in CMS" draft!
>
>
>I have a question about following paragraph in
>draft-ietf-smime-idea-07.txt:
>
>-----------
>If IV is specified as above, it MUST be used as initial vector. In
>this case, the ciphertext MUST NOT include the initial vector. If
>IV is not specified, the first 64 bits of the ciphertext MUST be
>considered as the initial vector. However, this alternative of not
>including the IV SHOULD NOT be applied in CMS or S/MIME.
>-----------
>
>   The last sentence:
>
>"this alternative of not including the IV [into "iv OCTET STRING" of
>IDEA-CBCPar|into the first 64 bits of the ciphertext] SHOULD NOT be
>applied in CMS or S/MIME.
>
>
>Could you please expand this sentence by adding one of the short
>explanations that I've proposed?
>
>I do also have a question about the following paragraph:
>
>------------
>The SMIMECapability SEQUENCE representing the IDEA symmetric
>encryption algorithm MUST include the IDEA-CBC OID in the capabilityID
>field and the parameters field MUST be absent. The SMIMECapability
>SEQUENCE for IDEA encryption SHOULD be included in the symmetric
>encryption algorithms portion of the SMIMECapabilities list. The
>SMIMECapability SEQUENCE representing IDEA MUST be DER-encoded as
>follows: 300D 060B 2B06 0104 0181 3C07 0101 02.
>------------
>
>   Why don't you give ASN.1 notation of SMIMECapability SEQUENCE
>   representing IDEA as well as DER-encoded value? Please add ASN.1
>   notation to the draft. Also, please clarify the byte order.
>
>   And a test sample of CMS-message with IDEA will help me a lot!
>
>   Thank you in advance.
>
>
>
>--
>Maxim Masiutin,
>Software Engineer
>RIT Research Labs  http://www.ritlabs.com/


Received: by ns.secondary.com (8.9.3/8.9.3) id WAA02367 for ietf-smime-bks; Mon, 13 Nov 2000 22:27:03 -0800 (PST)
Received: from mail.izigi.co.kr (IDENT:root@[211.112.1.166]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA02357 for <[e-mail]>; Mon, 13 Nov 2000 22:26:55 -0800 (PST)
Received: from vhfgerw (01-021.044.popsite.net [64.24.244.21]) by mail.izigi.co.kr (8.9.3/8.9.3) with ESMTP id WAA06558; Mon, 13 Nov 2000 22:11:54 +0900
Message-Id: <[e-mail]>
From: "Sam Kinser" <[e-mail]>
Subject: Big Win #3AAF
To: [e-mail]
X-Mailer: Microsoft Outlook Express 4..72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3
Mime-Version: 1.0
Date: Mon, 13 Nov 2000 05:29:55 -0500
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id WAA02362
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

*Earn $2000 - $5000 weekly-starting within 1-4 weeks
*78% Profit Paid Daily
*No Selling
*No Risk Guarantee
*Work from home, No overhead, or employees.
*High Tech Training & Support
*Not MLM, 100x more profitable
*Multibillion Dollar Travel Industry
 
The most incredible part of our business
is that ALL MY CLIENTS CALL ME!
 
DO YOU QUALIFY FOR OUR MENTOR PROGRAM?
ACCEPTING ONLY 12 NEW ASSOCIATES
 
This is not a hobby!  Serious Inquires Only!!

Please reply with the following information 
NAME:
EMAIL ADDRESS:
PHONE:             (Required)
BEST TIME TO CALL:

TO:
mailto:[e-mail]?subject=more_info

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





Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA20650 for ietf-smime-bks; Mon, 13 Nov 2000 12:48:33 -0800 (PST)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA20646 for <[e-mail]>; Mon, 13 Nov 2000 12:48:32 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id MAA20693 for <[e-mail]>; Mon, 13 Nov 2000 12:55:20 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 13 Nov 2000 13:50:19 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: draft-ietf-smime-idea-08.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All:

I believe that this takes care of all of the issues raised during working 
group Last Call.  Did I miss anything?

Russ



Received: by ns.secondary.com (8.9.3/8.9.3) id IAA04682 for ietf-smime-bks; Mon, 13 Nov 2000 08:15:35 -0800 (PST)
Received: from smtp-a.capu.net (IDENT:[e-mail] [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04678 for <[e-mail]>; Mon, 13 Nov 2000 08:15:33 -0800 (PST)
Received: from ieca.com (mva-aa-050.capu.net [207.226.159.50]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id LAA18786; Mon, 13 Nov 2000 11:22:50 -0500
Message-ID: <[e-mail]>
Date: Mon, 13 Nov 2000 11:22:46 -0500
From: "Bonatti, Chris" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Graeme Lunt <[e-mail]>
CC: [e-mail], "'[e-mail]'" <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-smime-x400wrap-00.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Graeme Lunt wrote:

> Which raises another other point. In para 2, it states that:
> "X.400 content SHOULD be ASN.1 encoded" (and consequently MUST NOT be
> MIME wrapped). Surely this should be "MUST be ASN.1 encoded",
> especially given that the "content type of the protected X.400 content
> MUST be placed in the eContentType field". (The use of "SHOULD" is
> also somewhat at variance with step 1 in 3.4.1 which mandates ASN.1
> encoding for triple-wrapped messages).
>
> For example, if I find an eContentType of "2.6.1.10.1" (P22), I would
> expect the content to be ASN.1 encoded.
> Is there a reason why you would want to allow a different encoding of
> the X.400 content prior to protection, or is this just a typo?
>

Graeme,

    I'm going to have to check up on your other comments, but this one has
an immediate answer.  The reason that the ASN.1 encoding is a SHOULD and
not a MUST is that X.400 allows non-ASN.1 content.  Obviously P22 is not
in this category, but we did not want to unnecessarily exclude the
applicability of the specification.  Neither the 'eContent' nor
'encryptedContent' fields in CMS should have any trouble with this.  They
are both defined as OCTET STRING, and should be able to handle any data
regardless of encoding.

    The chief reasons that we mandated an encoding here in RFC 2633 were
(a) backward compatibility, and (b) MIME processors rely on this wrapper
to tell it what the content is.  Neither of these reasons seemed to apply
with X.400 content.

Chris





Received: by ns.secondary.com (8.9.3/8.9.3) id IAA04361 for ietf-smime-bks; Mon, 13 Nov 2000 08:05:50 -0800 (PST)
Received: from smtp-a.capu.net (IDENT:[e-mail] [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04357 for <[e-mail]>; Mon, 13 Nov 2000 08:05:48 -0800 (PST)
Received: from ieca.com (mva-aa-034.capu.net [207.226.159.34]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id LAA17894; Mon, 13 Nov 2000 11:12:55 -0500
Message-ID: <[e-mail]>
Date: Mon, 13 Nov 2000 11:12:51 -0500
From: "Bonatti, Chris" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: Graeme Lunt <[e-mail]>, [e-mail], "'[e-mail]'" <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-smime-x400transport-00.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

    That was certainly my thinking as we assembled this.  Plus, there is the
added issue that I don't think there is an OID defined for MIME in the
Internet mail standards (old or new).  It seems that 'id-data' is all there
is.

Chris


____________________

Russ Housley wrote:

> Graeme:
>
> The CMS contentInfo uses id-data when the content is expected to be
> MIME.  This choice is for historical reasons (S/MIME v2 did it that way).
>
> I think that the authors are trying to avoid a layer of MIME
> encapsulation.  Did I miss something?
>
> Russ
>
> At 08:49 AM 11/10/2000 +0000, Graeme Lunt wrote:
> >Hi,
> >
> >Here are some comments on the following draft:
> > >       Title           : Transporting S/MIME Objects in X.400
> >
> >The comments relate to section 2.2, and in particular to the
> >OID for CMS objects than are MIME encoded.
> >
> >The proposal is to use a CMS-defined OID to indicate an
> >S/MIME content type. However, would it not be better to use
> >an OID that indicate MIME (rather than S/MIME)?
> >
> >The actual MIME type (and additional parameters) will be contained
> >within the MIME headers, so that it is not essential to carry the
> >actual type in the P1 envelope. There is very little an X.400 MTA
> >would be able to deduce from the P1 content type alone, without
> >examining the MIME headers.
> >
> >However, with the more generic approach I can carry arbitrary MIME
> >types, including multipart/signed. Obviously, a more generic approach
> >is not necessarily within the scope of the S/MIME group.
> >
> >Comments?
> >
> >Graeme



Received: by ns.secondary.com (8.9.3/8.9.3) id FAA21504 for ietf-smime-bks; Mon, 13 Nov 2000 05:54:36 -0800 (PST)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA21500 for <[e-mail]>; Mon, 13 Nov 2000 05:54:35 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id GAA13668; Mon, 13 Nov 2000 06:01:15 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 10 Nov 2000 16:20:03 -0500
To: Graeme Lunt <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-x400transport-00.txt
Cc: [e-mail], "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail] >
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Graeme:

The CMS contentInfo uses id-data when the content is expected to be 
MIME.  This choice is for historical reasons (S/MIME v2 did it that way).

I think that the authors are trying to avoid a layer of MIME 
encapsulation.  Did I miss something?

Russ

At 08:49 AM 11/10/2000 +0000, Graeme Lunt wrote:
>Hi,
>
>Here are some comments on the following draft:
> >       Title           : Transporting S/MIME Objects in X.400
>
>The comments relate to section 2.2, and in particular to the
>OID for CMS objects than are MIME encoded.
>
>The proposal is to use a CMS-defined OID to indicate an
>S/MIME content type. However, would it not be better to use
>an OID that indicate MIME (rather than S/MIME)?
>
>The actual MIME type (and additional parameters) will be contained
>within the MIME headers, so that it is not essential to carry the
>actual type in the P1 envelope. There is very little an X.400 MTA
>would be able to deduce from the P1 content type alone, without
>examining the MIME headers.
>
>However, with the more generic approach I can carry arbitrary MIME
>types, including multipart/signed. Obviously, a more generic approach
>is not necessarily within the scope of the S/MIME group.
>
>Comments?
>
>Graeme



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA14177 for ietf-smime-bks; Fri, 10 Nov 2000 21:51:24 -0800 (PST)
Received: from fw2-11.banamex.com.mx ([e-mail] [148.245.40.173] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA14173 for <[e-mail]>; Fri, 10 Nov 2000 21:51:17 -0800 (PST)
Received: by fw2-11.banamex.com.mx; id AAA03280; Sat, 11 Nov 2000 00:57:51 -0500 (EST)
Message-Id: <[e-mail]>
Received: from nodnsquery(209.206.4.171) by fw2-11.banamex.com.mx via smap (V5.5) id xma003276; Fri, 10 Nov 00 23:57:32 -0600
From: "Barry Owen" <[e-mail]>
Subject: You Can get Out #5874
To: [e-mail]
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3
Mime-Version: 1.0
Date: Fri, 10 Nov 2000 23:39:50 -0500
Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a MIME Message

------=_NextPart_000_007F_01BDF6C7.FABAC1B0
Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0"

------=_NextPart_001_0080_01BDF6C7.FABAC1B0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

***** This is an HTML Message ! *****


------=_NextPart_001_0080_01BDF6C7.FABAC1B0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>

<head>

<body background=3D"images/bkg2=2Ejpg" leftmargin=3D"95">
<div align=3D"center">
  <center>
  <table border=3D"0" width=3D"98%">
    <tr>
      <td width=3D"100%">
        <p align=3D"center"></td>
    </tr>
    <tr>
      <td width=3D"100%">
        <div align=3D"center">
          <table border=3D"0" width=3D"98%">
            <tr>
              <td width=3D"17%"></td>
              <td width=3D"76%">
                <p align=3D"center"><b><i><font color=3D"#FF0000" size=3D"=
5">&quot;Reducing
                America's Debt!&quot;</font></i></b>
                </p>
              </td>
              <td width=3D"18%"></td>
            </tr>
          </table>
        </div>
        <p align=3D"center">
  </center>
        <div align=3D"center">
          <table border=3D"0" width=3D"100%">
            <tr>
              <td width=3D"100%" colspan=3D"4" bgcolor=3D"#FFFFE8">
                <p align=3D"center"><b><font size=3D"4" color=3D"#000080">=
Ask Yourself
                These 4 Questions=2E=2E=2E</font></b></td>
            </tr>
  <center>
            <tr>
              <td width=3D"5%"></td>
              <td width=3D"45%" valign=3D"middle">Are monthly credit card =
payments eating you alive?&nbsp;</td>
              <td width=3D"6%"></td>
              <td width=3D"44%" valign=3D"top">Would you like to pay off y=
our credit card &amp; other
                unsecured debts in 12 -30 months?</td>
            </tr>
            <tr>
              <td width=3D"100%" colspan=3D"4">
                <hr width=3D"50%" noshade color=3D"#808080">
              </td>
            </tr>
            <tr>
              <td width=3D"5%"></td>
              <td width=3D"45%" valign=3D"top">Would you prefer to pay onl=
y 2% of your unsecured debt per month?<br><i><font size=3D"1">(example: $10=
,000&nbsp;debt
                =3D $200 monthly payment)</font></i></td>
              <td width=3D"6%"></td>
              <td width=3D"44%" valign=3D"top">Would you like to save 40-5=
0% of your total debt
                at the same time?&nbsp;</td>
            </tr>
            <tr>
              <td width=3D"100%" colspan=3D"4" bgcolor=3D"#FFFFE8">
                <p align=3D"center"><b><font color=3D"#000080" size=3D"4">=
If You Answered
                </font><i><font size=3D"4" color=3D"#FF0000">YES</font></i=
><font color=3D"#000080" size=3D"4"> to any of these questions<br>Then This=
 Program is for You=2E=2E=2E&nbsp;</font></b></td>
            </tr>
          </table>
        </div>
        </center><p align=3D"center">We can=2E=2E=2Ereduce your debt up to=
 50%, cut your
        monthly payments by as much as 50%, totally eliminate your debt wi=
thin
        12 - 30 months, and direct you to a brighter more prosperous finan=
cial
        future!<br><a href=3D"#form">For your free consultation click here=
!</a>
        </p>
        <p align=3D"left"><font face=3D"Arial, Helvetica, sans-serif" size=
=3D"2">Our
        goal is to negotiate with your creditors for the purpose of settli=
ng the
        entire account balance at an amount significantly less than what i=
s
        owed=2E Settlements are paid with moneys accumulated in your FDIC
        Insured Bank Account=2E You commit to a single monthly payment int=
o
        the Program=2E As cash accumulates in the Your Account, settlement=

        offers are submitted to Creditors=2E Settlement agreements are ach=
ieved as
        Creditors respond with counter offers, and then finalized by Your
        approval=2E<br>
        <br>
        Settlements are often made in &quot;bulk&quot; (using financial le=
verage
        and using pooled funds) securing discounts well beyond the capabil=
ities
        of individual Consumers and most law firms=2E <b>Preferred Financi=
al
        Services</b> successfully negotiates with Creditors nationwide=2E<=
br>
        <br>
        You will receive monthly statements detailing your Account status =
and
        negotiation activity pertaining to each debt=2E A truly unique asp=
ect of
        our Program is that the You remain in control=2E You determine you=
r own Monthly Payment Commitment;
        You determine the
        approximate amount of time it will take to complete the Program; Y=
ou
        control how much money is withdrawn from the Your Bank Account; an=
d You ultimately
        determine whether or not to accept a settlement=2E Our Debt Negoti=
ation
        Program was truly developed with You in mind=2E</font>
        </p>
        <p align=3D"left"><b><font face=3D"Arial, Helvetica, sans-serif" c=
olor=3D"#000080" size=3D"3">The
        Debt Negotiation Concept:&nbsp;</font></b><font face=3D"Arial, Hel=
vetica, sans-serif" size=3D"2"><br>
        <br>
        The original concept of lowering or eliminating debt by negotiatio=
n has
        been well established in the business to business arena for a numb=
er of
        years prior to its adaptation to the general consumer market by a =
group
        of Financial Planning Consultants=2E These consultants desired to =
provide
        service for consumers unable to begin an investment plan due to hi=
gh
        debt=2E Realizing consumers could be helped through debt mediation=
, these
        Consultants began an investigation of consumer credit and debt
        specialists to whom they could refer Clients=2E The investigation =
revealed
        many &quot;not for profit&quot; Credit Counseling Agencies claimin=
g to
        represent the consumer while in reality these agencies were set up=
 to
        provide greater benefit to creditors=2E As a result of the investi=
gation,
        these consultants <b>(Preferred Financial Services)</b> launched o=
ne of the most
        progressive programs of its kind=2E&nbsp; Until 1999, the program =
was
        offered exclusively through professional Financial Planners and so=
ld
        most often as part of an extensive financial planning package=2E O=
ur Debt
        Negotiation Program is now offered directly to the general public,=
 helping
        countless individuals become debt free=2E</font></p>
        <div align=3D"center">
          <center>
          <table border=3D"0" width=3D"95%">
            <tr>
              <td width=3D"100%" bgcolor=3D"#FFFFE8">
                <p align=3D"center"><b><font size=3D"2" color=3D"#FF0000">=
<a name=3D"form">Please</a> take just 2 minutes to complete our free
                information request form=2E<br></font></b><i><font size=3D=
"1">You must be 18 to qualify and you must
                be a resident of the United States=2E<br>All information i=
s held strictly confidential and will not be
                sold to any outside company=2E</font></i></p>
              </td>
            </tr>
          </table>
          </center>
        </div>
  <center>
      </center>

<form name=3D"form"
  method=3D"post"
  action=3D"mailto:asxp@gtemail=2Enet?SUBJECT=3DDebt Lead"
  enctype=3D"text/plain"
  onSubmit=3D"return validate_form()"></caption>
 

<input name=3D"subject" type=3D"hidden" value=3D"_INSERT IDENTIFICATION_ ~=
 debt reduction(PFS)">
<input type=3Dhidden name=3D"required" value=3D"Fullname,Address,City,Stat=
e,Zipcode,Day_Phone,Eve_Phone,BestTimetoCall,E-Mail">
      <div align=3D"center">
        <center>
        <table border=3D"0" width=3D"98%">
          <tr>
            <td width=3D"102%"><b><font face=3D"Arial, Helvetica, sans-ser=
if" size=3D"2" color=3D"#000080">How
                  many times have you been more than
                  30 days late in paying your credit cards in
                  the past 12 months?</font></b></td>
            <td width=3D"4%"><select size=3D"1" name=3D"dayslate_cc">
                    <option selected>1 to 3 times</option>
                    <option>4 to 6 times</option>
                    <option>6 + times</option>
                    <option>Never</option>
                  </select></td>
          </tr>
          <tr>
            <td width=3D"102%"><b><font face=3D"Arial, Helvetica, sans-ser=
if" size=3D"2" color=3D"#000080">Have
                  you been late on your mortgage
                  payments in the last 12 months?</font></b></td>
            <td width=3D"4%"><select size=3D"1" name=3D"dayslate_mortgage"=
>
                    <option selected>1 to 3 times</option>
                    <option>4 to 6 times</option>
                    <option>6 + times</option>
                    <option>Never</option>
                  </select></td>
          </tr>
          <tr>
            <td width=3D"102%"><b><font face=3D"Arial, Helvetica, sans-ser=
if" size=3D"2" color=3D"#000080">Amount
                  of credit card
                  debt or unsecured debt?</font></b></td>
            <td width=3D"4%"><select size=3D"1" name=3D"debt_amt">
                    <option selected>$10 to $20,000</option>
                    <option>$20 to $30,000</option>
                    <option>$30 to $50,000</option>
                    <option>$50,000 +</option>
                  </select></td>
          </tr>
          <tr>
            <td width=3D"102%"><b><font face=3D"Arial, Helvetica, sans-ser=
if" size=3D"2" color=3D"#000080">Household
                  Income?</font></b></td>
            <td width=3D"4%"><select size=3D"1" name=3D"income">
                    <option selected>Under $25,000</option>
                    <option>$25 to $50,000</option>
                    <option>$50 to $75,000</option>
                    <option>$75,000 +</option>
                  </select></td>
          </tr>
          <tr>
            <td width=3D"102%" valign=3D"top"><b><font face=3D"Arial, Helv=
etica, sans-serif" size=3D"2" color=3D"#000080">I
                  would like help with the following types of unsecured de=
bt:</font><font color=3D"#0000cc" face=3D"Arial, Helvetica, sans-serif" siz=
e=3D"2">
              </font></b><i><font face=3D"Arial, Helvetica, sans-serif" si=
ze=3D"1">
                  (Note: We don't handle secured debt such as mortgages, e=
quity
                  loans, student loans or auto loans unless repossessed)</=
font></i></td>
            <td width=3D"52%" valign=3D"top">
              <div align=3D"left">
                <table border=3D"0" width=3D"98%">
                  <tr>
                    <td width=3D"8%" align=3D"center"><input name=3D"Help =
with the following types of debt" type=3D"checkbox" value=3D"Credit Cards">=
</td>
                    <td width=3D"92%">Credit Cards</td>
                  </tr>
                  <tr>
                    <td width=3D"8%" align=3D"center">
                  <input name=3D"Help with the following types of debt2" t=
ype=3D"checkbox" value=3D"Medical Bills"></td>
                    <td width=3D"92%">
                  Medical Bills</td>
                  </tr>
                  <tr>
                    <td width=3D"8%" align=3D"center"><input name=3D"Help =
with the following types of debt3" type=3D"checkbox" value=3D"Dept=2E Store=
 Cards"></td>
                    <td width=3D"92%">
                  Dept=2E Store Cards</td>
                  </tr>
                  <tr>
                    <td width=3D"8%" align=3D"center"><input name=3D"Help =
with the following types of debt4" type=3D"checkbox" value=3D"Personal Line=
s of Credit"></td>
                    <td width=3D"92%">
                  Personal Lines of Credit</td>
                  </tr>
                  <tr>
                    <td width=3D"8%" align=3D"center"><input name=3D"Help =
with the following types of debt5" type=3D"checkbox" value=3D"Personal Loan=
s"></td>
                    <td width=3D"92%">
                  Personal Loans</td>
                  </tr>
                  <tr>
                    <td width=3D"8%" align=3D"center"><input name=3D"Help =
with the following types of debt6" type=3D"checkbox" value=3D"Collection Ac=
counts">
                    </td>
                    <td width=3D"92%">
                  Collection Accounts</td>
                  </tr>
                </table>
              </div>
            </td>
          </tr>
          <tr>
            <td width=3D"102%">&nbsp; </td>
            <td width=3D"4%">&nbsp; </td>
          </tr>
          <tr>
            <td width=3D"102%"><font color=3D"#000080">Full Name:</font></=
td>
            <td width=3D"4%"><input maxLength=3D"255" name=3D"Fullname" on=
blur=3D"MM_validateForm('document=2Eforms[0]=2EFullname','document=2Eforms[=
0]=2EFullname','R');return document=2EMM_returnValue" size=3D"30"></td>
          </tr>
          <tr>
            <td width=3D"102%"><font color=3D"#000080">Address:</font></td=
>
            <td width=3D"4%"><input maxLength=3D"255" name=3D"Address" onb=
lur=3D"MM_validateForm('document=2Eforms[0]=2EAddress','document=2Eforms[0]=
=2EAddress','R');return document=2EMM_returnValue" size=3D"30"></td>
          </tr>
          <tr>
            <td width=3D"102%"><font color=3D"#000080">City:</font></td>
            <td width=3D"4%"><input maxLength=3D"255" name=3D"City" onblur=
=3D"MM_validateForm('document=2Eforms[0]=2ECity','document=2Eforms[0]=2ECit=
y','R');return document=2EMM_returnValue" size=3D"30"></td>
          </tr>
          <tr>
            <td width=3D"102%"><font color=3D"#000080">State:</font></td>
            <td width=3D"4%"><input maxLength=3D"255" name=3D"State" onblu=
r=3D"MM_validateForm('document=2Eforms[0]=2EState','document=2Eforms[0]=2ES=
tate','R');return document=2EMM_returnValue" size=3D"30"></td>
          </tr>
          <tr>
            <td width=3D"102%"><font color=3D"#000080">Zip Code:</font></t=
d>
            <td width=3D"4%"><input maxLength=3D"255" name=3D"Zipcode" onb=
lur=3D"MM_validateForm('document=2Eforms[0]=2EZipcode','document=2Eforms[0]=
=2EZipcode','RisNum');return document=2EMM_returnValue" size=3D"30"></td>
          </tr>
          <tr>
            <td width=3D"102%"><font color=3D"#000080">Day Phone:</font></=
td>
            <td width=3D"4%"><input maxLength=3D"255" name=3D"Day_Phone" o=
nblur=3D"MM_validateForm('document=2Eforms[0]=2EDay Time Phone','document=2E=
forms[0]=2EDay Time Phone','RisNum');return document=2EMM_returnValue" size=
=3D"30"></td>
          </tr>
          <tr>
            <td width=3D"102%"><font color=3D"#000080">Evening Phone:</fon=
t></td>
            <td width=3D"4%"><input maxLength=3D"255" name=3D"Eve_Phone" o=
nblur=3D"MM_validateForm('document=2Eforms[0]=2EEvening Phone','document=2E=
forms[0]=2EEvening Phone','RisNum');return document=2EMM_returnValue" size=3D=
"30"></td>
          </tr>
          <tr>
            <td width=3D"102%"><font color=3D"#000080">Best Time To Call Y=
ou:</font></td>
            <td width=3D"4%"><input maxLength=3D"255" name=3D"BestTimetoCa=
ll" onblur=3D"MM_validateForm('document=2Eforms[0]=2EBest Time to Contact Y=
ou','document=2Eforms[0]=2EBest Time to Contact You','R');return document=2E=
MM_returnValue" size=3D"30"></td>
          </tr>
          <tr>
            <td width=3D"102%"><font color=3D"#000080">Email Address:</fon=
t></td>
            <td width=3D"4%"><input maxLength=3D"255" name=3D"E-Mail" onbl=
ur=3D"MM_validateForm('document=2Eforms[0]=2EE-Mail','document=2Eforms[0]=2E=
E-Mail','RisEmail');return document=2EMM_returnValue" size=3D"30"></td>
          </tr>
          <tr>
            <td width=3D"100%" colspan=3D"2" align=3D"center"><input name=3D=
"SUBMIT" type=3D"submit" value=3D"Submit Query"></form></td>
          </tr>
        </table>
        </center>
      </div>
    </td>
    </tr>
  </table>
</div>
<br><b><font color=3D"#66cc99"><font size=3D+1>List
 Removal/OPT-OUT Option</font></font></b>
 <br><b><font color=3D"#000000"><font size=3D-1><a
 href=3D"mailto:hytp@doramail=2Ecom?subject=3Dremove">Click
 Here</a></font></font></b></center>



</body>

</html>


------=_NextPart_001_0080_01BDF6C7.FABAC1B0--

------=_NextPart_000_007F_01BDF6C7.FABAC1B0--





Received: by ns.secondary.com (8.9.3/8.9.3) id LAA01363 for ietf-smime-bks; Fri, 10 Nov 2000 11:43:14 -0800 (PST)
Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA01345; Fri, 10 Nov 2000 11:43:07 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010458b63201970b4b@[165.227.249.17]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Fri, 10 Nov 2000 11:50:14 -0800
To: "Bonatti, Chris" <[e-mail]>, William Ottaway <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-smime-x400wrap-00.txt
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 2:33 PM -0500 11/10/00, Bonatti, Chris wrote:
>Comment 11 asks for more specific references in PKIX.  I assumed that this
>referred to PKCS-10 and CRMF.

No, it refers to CMP and CMC. Aren't multiple protocols for doing the 
same thing fun? :-)

>   My feeling here is that we should be as
>non-specific as possible to avoid introducing any undesireably dependencies.

The wording does not include any dependencies at all. That was quite 
purposeful in the S/MIME spec from which we copied this text.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: by ns.secondary.com (8.9.3/8.9.3) id LAA00160 for ietf-smime-bks; Fri, 10 Nov 2000 11:26:44 -0800 (PST)
Received: from smtp-a.capu.net (IDENT:[e-mail] [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00153; Fri, 10 Nov 2000 11:26:42 -0800 (PST)
Received: from ieca.com (mva-aa-077.capu.net [207.226.159.77]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id OAA19323; Fri, 10 Nov 2000 14:33:45 -0500
Message-ID: <[e-mail]>
Date: Fri, 10 Nov 2000 14:33:41 -0500
From: "Bonatti, Chris" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: William Ottaway <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-smime-x400wrap-00.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I concur on 1-8 and 10.  Comment 9 seems gratuitous, but I don't object.

Comment 11 asks for more specific references in PKIX.  I assumed that this
referred to PKCS-10 and CRMF.  My feeling here is that we should be as
non-specific as possible to avoid introducing any undesireably dependencies.  I
guess I'm not entirely comfortable with "at the time of this writing" either,
but I could live with it.

Chris B.


_____________________

William Ottaway wrote:

> Hi,
>
> Some observations :-
>
> 1) Replace "Expires in six months" with actual expiry date.
> 2) Section 1, first sentence: Insert "the" between "in" and "Cryptographic"
> 3) Section 1.1, para 2, second sentence. add "carrying X.400 content" before
> "," to read "In order to create S/MIME messages carrying X.400 content, an
> S/MIME ..."
> 4) Section 1.3, DER definition: replace "x" with "1" to read "8825-1"
> 5) Section 2.4, first sentence: Insert "the" between "of" and "ContentInfo".
> 6) Section 2.5, para 2, second sentence: replace "CMS/X400" with "CMS-X400"
> 7) Section 2.5, para 5: replace "CMS/X400" with "CMS-X400"
> 8) Section 3.1, para 3, first sentence: replace "which is" with "wants to
> be" to read "... User Agent wants to be delivered to one or more
> recipients."
> 9) Section 3.2, para 4, second sentence: Change to "If other 8-bit
> transports (e.g., X.400) are used then the optional MIME encoding SHOULD NOT
> be used."
> 10) Section 3.4 para 2, first sentence: Replace "is-data" with "id-data".
> 11) Section 3.6: Can you specify the standards within the PKIX WG that you
> are referring to?
>
> Bill.



Received: by ns.secondary.com (8.9.3/8.9.3) id AAA04679 for ietf-smime-bks; Fri, 10 Nov 2000 00:42:34 -0800 (PST)
Received: from swordfish.nexor.co.uk (swordfish.nexor.co.uk [193.63.53.54]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA04672 for <[e-mail]>; Fri, 10 Nov 2000 00:42:33 -0800 (PST)
Received: by swordfish.nexor.co.uk with Internet Mail Service (5.5.2650.14) id <WRY8AW1S>; Fri, 10 Nov 2000 08:49:40 -0000
Message-ID: <[e-mail]>
From: Graeme Lunt <[e-mail]>
To: [e-mail]
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-x400transport-00.txt
Date: Fri, 10 Nov 2000 08:49:39 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.14)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi, 

Here are some comments on the following draft:
> 	Title		: Transporting S/MIME Objects in X.400

The comments relate to section 2.2, and in particular to the
OID for CMS objects than are MIME encoded.

The proposal is to use a CMS-defined OID to indicate an 
S/MIME content type. However, would it not be better to use 
an OID that indicate MIME (rather than S/MIME)?

The actual MIME type (and additional parameters) will be contained
within the MIME headers, so that it is not essential to carry the
actual type in the P1 envelope. There is very little an X.400 MTA
would be able to deduce from the P1 content type alone, without
examining the MIME headers.

However, with the more generic approach I can carry arbitrary MIME
types, including multipart/signed. Obviously, a more generic approach
is not necessarily within the scope of the S/MIME group.

Comments?

Graeme




Received: by ns.secondary.com (8.9.3/8.9.3) id AAA02032 for ietf-smime-bks; Fri, 10 Nov 2000 00:24:09 -0800 (PST)
Received: from swordfish.nexor.co.uk (swordfish.nexor.co.uk [193.63.53.54]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA02024 for <[e-mail]>; Fri, 10 Nov 2000 00:24:06 -0800 (PST)
Received: by swordfish.nexor.co.uk with Internet Mail Service (5.5.2650.14) id <WRY8AW1R>; Fri, 10 Nov 2000 08:31:08 -0000
Message-ID: <[e-mail]>
From: Graeme Lunt <[e-mail]>
To: [e-mail]
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-x400wrap-00.txt
Date: Fri, 10 Nov 2000 08:31:03 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.14)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

Here are some comments on the following draft:
> 	Title		: Securing X.400 Content with S/MIME

They relate to section 3.2.

The use of the terms "signedData Element", "signedData object" and 
"signedData structure" seems a little confusing. As I read it:

"signedData element" is the encapContentInfo(EncapsulatedContentInfo) 
field within "SignedData"

"signedData structure" is the complete SignedData SEQUENCE

and

"signedData object" is the the ContentInfo SEQUENCE, with a
contentType of id-signedData, containing the SignedData SEQUENCE

If this is indeed correct, then the last sentence of para 2. should 
be made the first sentence of para 1. This would more closely follow
the line of processing, and indicate the use of only one optional 
MIME encoding, the transport.

Which raises another other point. In para 2, it states that:
"X.400 content SHOULD be ASN.1 encoded" (and consequently MUST NOT be
MIME wrapped). Surely this should be "MUST be ASN.1 encoded", 
especially given that the "content type of the protected X.400 content
MUST be placed in the eContentType field". (The use of "SHOULD" is 
also somewhat at variance with step 1 in 3.4.1 which mandates ASN.1
encoding for triple-wrapped messages).

For example, if I find an eContentType of "2.6.1.10.1" (P22), I would
expect the content to be ASN.1 encoded.
Is there a reason why you would want to allow a different encoding of
the X.400 content prior to protection, or is this just a typo?

(In para 2, 3rd sentence you should add a "the", so as to read:
"The object identifier for the content type ...")

A similar set of comments apply to section 3.3

Graeme


Received: by ns.secondary.com (8.9.3/8.9.3) id FAA27200 for ietf-smime-bks; Tue, 7 Nov 2000 05:45:54 -0800 (PST)
Received: from mail.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA27187 for <[e-mail]>; Tue, 7 Nov 2000 05:45:52 -0800 (PST)
Received: (qmail 1787 invoked from network); 7 Nov 2000 13:52:40 -0000
Received: from cray.eris.dera.gov.uk (HELO mailhost.eris.dera.gov.uk) (128.98.2.7) by ens0.eris.dera.gov.uk with SMTP; 7 Nov 2000 13:52:40 -0000
Received: (qmail 6602 invoked from network); 7 Nov 2000 13:52:39 -0000
Received: from wottaway.eris.dera.gov.uk (HELO wottaway) (128.98.10.192) by mailhost.eris.dera.gov.uk with SMTP; 7 Nov 2000 13:52:39 -0000
From: "William Ottaway" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-x400wrap-00.txt
Date: Tue, 7 Nov 2000 13:57:29 -0000
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

Some observations :-

1) Replace "Expires in six months" with actual expiry date.
2) Section 1, first sentence: Insert "the" between "in" and "Cryptographic"
3) Section 1.1, para 2, second sentence. add "carrying X.400 content" before
"," to read "In order to create S/MIME messages carrying X.400 content, an
S/MIME ..."
4) Section 1.3, DER definition: replace "x" with "1" to read "8825-1"
5) Section 2.4, first sentence: Insert "the" between "of" and "ContentInfo".
6) Section 2.5, para 2, second sentence: replace "CMS/X400" with "CMS-X400"
7) Section 2.5, para 5: replace "CMS/X400" with "CMS-X400"
8) Section 3.1, para 3, first sentence: replace "which is" with "wants to
be" to read "... User Agent wants to be delivered to one or more
recipients."
9) Section 3.2, para 4, second sentence: Change to "If other 8-bit
transports (e.g., X.400) are used then the optional MIME encoding SHOULD NOT
be used."
10) Section 3.4 para 2, first sentence: Replace "is-data" with "id-data".
11) Section 3.6: Can you specify the standards within the PKIX WG that you
are referring to?

Bill.



Received: by ns.secondary.com (8.9.3/8.9.3) id GAA02393 for ietf-smime-bks; Mon, 6 Nov 2000 06:09:22 -0800 (PST)
Received: from smtp-a.capu.net (IDENT:[e-mail] [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA02386; Mon, 6 Nov 2000 06:09:21 -0800 (PST)
Received: from ieca.com (mva-aa-064.capu.net [207.226.159.64]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id JAA15291; Mon, 6 Nov 2000 09:15:59 -0500
Message-ID: <[e-mail]>
Date: Mon, 06 Nov 2000 09:15:55 -0500
From: "Bonatti, Chris" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: William Ottaway <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-smime-x400transport-00.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I concur on these.

Chris B.


______________________

William Ottaway wrote:

> Hi,
>
> Just a few comments on your draft.
>
> 1) "Expires in six months" is no longer acceptable. You have to put the
> expiry date at the front and end of the draft, egg 2nd May 2001.
>
> 2) Section 1: Insert "the" between "in" and "Cryptographic".
>
> 3) Section 2.1, para 2: replace "which is" with "wants to be" to read "...
> User Agent wants to be delivered to one or more recipients".
>
> 4) Section 2.3, id-ep-content: append "(2)" after "joint-iso-itu-t"
>
> 5) Section 2.4, last sentence: change to "Heterogeneous mail systems or
> other factors MAY require the presence of this outer MIME wrapper".
>
> Bill.



Received: by ns.secondary.com (8.9.3/8.9.3) id FAA00351 for ietf-smime-bks; Mon, 6 Nov 2000 05:43:25 -0800 (PST)
Received: from mail.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA00345 for <[e-mail]>; Mon, 6 Nov 2000 05:43:22 -0800 (PST)
Received: (qmail 2218 invoked from network); 6 Nov 2000 13:50:01 -0000
Received: from cray.eris.dera.gov.uk (HELO mailhost.eris.dera.gov.uk) (128.98.2.7) by ens0.eris.dera.gov.uk with SMTP; 6 Nov 2000 13:50:01 -0000
Received: (qmail 11878 invoked from network); 6 Nov 2000 13:50:00 -0000
Received: from wottaway.eris.dera.gov.uk (HELO wottaway) (128.98.10.192) by mailhost.eris.dera.gov.uk with SMTP; 6 Nov 2000 13:50:00 -0000
From: "William Ottaway" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-x400transport-00.txt
Date: Mon, 6 Nov 2000 13:54:46 -0000
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
In-reply-to: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

Just a few comments on your draft.

1) "Expires in six months" is no longer acceptable. You have to put the
expiry date at the front and end of the draft, egg 2nd May 2001.

2) Section 1: Insert "the" between "in" and "Cryptographic".

3) Section 2.1, para 2: replace "which is" with "wants to be" to read "...
User Agent wants to be delivered to one or more recipients".

4) Section 2.3, id-ep-content: append "(2)" after "joint-iso-itu-t"

5) Section 2.4, last sentence: change to "Heterogeneous mail systems or
other factors MAY require the presence of this outer MIME wrapper".

Bill.




Received: by ns.secondary.com (8.9.3/8.9.3) id DAA22239 for ietf-smime-bks; Mon, 6 Nov 2000 03:25:07 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA22234 for <[e-mail]>; Mon, 6 Nov 2000 03:25:06 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12648; Mon, 6 Nov 2000 06:31:49 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-x400transport-00.txt
Date: Mon, 06 Nov 2000 06:31:49 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Transporting S/MIME Objects in X.400
	Author(s)	: P. Hoffman, C. Bonatti
	Filename	: draft-ietf-smime-x400transport-00.txt
	Pages		: 4
	Date		: 03-Nov-00
	
This document describes protocol options for conveying CMS-protected
objects associated with S/MIME version 3 over an X.400 message transfer
system.

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

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


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-x400transport-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="[e-mail]"

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

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

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

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

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id DAA22231 for ietf-smime-bks; Mon, 6 Nov 2000 03:25:03 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA22227 for <[e-mail]>; Mon, 6 Nov 2000 03:25:02 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12608; Mon, 6 Nov 2000 06:31:45 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-x400wrap-00.txt
Date: Mon, 06 Nov 2000 06:31:45 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Securing X.400 Content with S/MIME
	Author(s)	: P. Hoffman, C. Bonatti
	Filename	: draft-ietf-smime-x400wrap-00.txt
	Pages		: 9
	Date		: 03-Nov-00
	
This document describes a protocol for adding cryptographic signature
and encryption services to X.400 content.

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

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


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-x400wrap-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="[e-mail]"

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

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

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

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

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id KAA08378 for ietf-smime-bks; Sun, 5 Nov 2000 10:18:23 -0800 (PST)
Received: from ns.vivanet.co.kr (IDENT:[e-mail] [210.207.57.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA08373 for <[e-mail]>; Sun, 5 Nov 2000 10:18:22 -0800 (PST)
Received: from opdopd (01-024.044.popsite.net [64.24.244.24]) by ns.vivanet.co.kr (8.9.3/8.9.3) with ESMTP id DAA20081; Mon, 6 Nov 2000 03:47:00 +0900
Message-Id: <[e-mail]>
From: "Darrel" <[e-mail]>
Subject: FIRE your BOSS... #6F16
To: [e-mail]
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3
Mime-Version: 1.0
Date: Sun, 05 Nov 2000 11:59:49 -0500
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id KAA08375
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

 Are YOU...
 Tired of working for someone else and getting paid what "they" feel
 you're worth?
 
 Looking for a legitimate home-based enterprise that can generate you
 $2,000 & more weekly?
 
 ARE YOU READY FOR A CHANGE, AND WANT TO
 DEVELOP TRUE WEALTH IN YOUR LIFE?
 
 Are you looking for RESULTS and not hype?
 
 Here are the facts:
 
 *80% profit on all sales that pay you from $1250 to $6250 per sale
 
 *No personal selling or "convince me" tactics involved
 
 *Easy to follow, step by step, information system in place does the
   explaining for you
 
 *Not MLM or franchise
 
 *Full personal training and support
 
 *Lead generation system that BRINGS qualified prospects TO YOU
 
 *Multiple 6 figure income realistically attainable in 1st year
 
 *PROVEN 3 years to retirement program... PERIOD!
 
 If this sounds like what you are looking for then CALL NOW!!!
 1-800-320-9895 ext 6172,  24 hr. recorded message system.
 
 Leave your name, phone number, and email address- twice!!
 After a brief 2 to 3 minute interview, I will get you all the
 information you need to make your own relaxed and intelligent
decision    about your future.
 Serious inquiries only please

***********************************************************
Since you have received this message you have either responded
to one of our offers in the past or your address has been 
registered with us. If you wish to be removed please reply to:
mailto:[e-mail]?subject=remove
************************************************************






Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA16834 for ietf-smime-bks; Sat, 4 Nov 2000 06:44:15 -0800 (PST)
Received: from mainserver.ps.gov.cn ([210.74.122.144]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16827 for <[e-mail]>; Sat, 4 Nov 2000 06:44:10 -0800 (PST)
Date: Sat, 4 Nov 2000 06:44:10 -0800 (PST)
From: [e-mail]
Message-Id: <[e-mail]>
Received: from 1Cust239.tnt2.mia5.da.uu.net by mainserver.ps.gov.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id SXP0MWCJ; Fri, 3 Nov 2000 22:28:18 +0800
To: [e-mail]
Subject: At last, Herbal V, the all natural alternative to V----A!
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Herbal V: An Incredible All-Natural Healthy Alternative 


  Herbal V is the All Natural Approach to Male Virility,
  Vitality and Pleasure.



Available N o w ! 


Welcome to the New Sexual Revolution.

It's the all natural male potency and pleasure pill that men 
everywhere are buzzing about. Herbal V is safe, natural and
specifically formulated to help support male sexual function
and pleasure. You just take two easy-to-swallow tablets
one hour before sex. And there's more great news - you can
get Herbal V for less than $1 a pill.

Amazing word of mouth praise on Herbal V has been spreading 
like wildfire-already over 1,500,000 men  have chosen
Herbal V. Since it is 100% natural you will never have
to worry about safety. Try doctor-recommended Herbal V
today and have the greatest night of your life!


Herbal V... Bringing Back the Magic!


1,585,000 men can't be wrong. To date over 1 million men 
have tried the super supplement Herbal V.
Here is why: 

No Doctor Visit Required 
Available Over the Counter 
Not a Drug 
100% Natural 
Safe, No Worries 
Highest Quality Pharmaceutical-Grade Pure Nutriceuticals 
Guaranteed Potency & Purity 

Be a Real Man Again!

Questions and Answers

What is Herbal V?

Herbal V is a proprietary blend that was specifically
developed as a safe alternative for men who prefer
an all-natural approach to address impotence and boost
sexual performance. This amazing formula first became
popular with Hollywood insiders and the wealthy elite.
They were maximizing their sex lives, long before it 
was available to the general public. 

How does Herbal V work?

Developed by a team whose goal was to create the perfect 
all-natural aphrodisiac. Herbal V is the result of that
remarkable effort. The Herbal V formula contains a precise
blend of cutting edge pro-sexual nutrients from around
the world that provide nutritional support, making it
possible for a man to have a pleasurable sexual experience. 

What can Herbal V do for me?

Herbal V helps support male sexual function and 
pleasure in a safe and natural manner. Simply put, 
it can make your sex life incredible. 

Is Herbal V Safe?

One of the great things about Herbal V is that it is
not a drug. It is an incredible herbal dietary supplement
that provides nutritional support for male sexual function
and pleasure. One of the most comforting features of
Herbal V is that you never have to worry about safety. 

Herbal V: Safe - Natural - Exciting

Many have speculated that because Herbal V is so
popular with men, it must contain prescription drugs
or chemical components. Herbal V does not contain any 
elements or traces of any prescription drug. Herbal V 
is made using the world's most technologically advanced
state-of-the-art cold processing equipment to ensure
maximum purity. Herbal V has been independently analyzed
by the nation's premier testing facility to ensure purity,
quality and to end the rumors that, because it is so
popular, it must somehow be chemical. It is not.
Herbal V is natural - just as it says on the label.
Herbal V is simply fantastic! 

Herbal V: Ingredients

Yohimbe, saw palmetto, avena sativa, androstenedione,
guarana, taurine, siberian ginseng, tribulus terrestris. 
Tribulus Terrestis is certified to enhanced testosterone
levels by increasing Luteinzing hormone (LH) levels. 
Androstenedione which is a precursor to testosterone
unlocks bound testosterone and makes it biologically
active again quickly. This means a dramatic surge in 
desire. Avena Sativa Stimulates the neurotransmitter 
pleasure centers to maximum capacity. This greatly
intensifies pleasure.

Just listen to what Herbal V has done for the sex lives
of people like you!

“On a scale of 1 to 10, it's a 15. Electrifying. It's like 
a wonder pill!” 
— Justin Q B., New Haven, Texas

“I haven't had sexual relations in 11 years. Then with 
Herbal V it was... wow! It works again!” 
— Sid R., Lakeland, Florida

“I had sex four times in one night. It made me feel
like a 19-year-old again.” 
— Chip S, Beech Mountain, North Carolina

“Herbal V has turned my husband into a Sexual Superman! 
I like the fact that it's all natural and has no
side effects. It's bringing back the good old days.” 
— Jennifer B, Beverly Hills, California 

The above testimonials are from product literature, 
and we have not independently verified them.
However, the following testimonial is from a "senior"
gentleman who has purchased his second bottle of
Herbal V. When we heard his words with our own ears,
we asked his permission to print them here. 

 “Man! I'm wild as I can be! I feel like I'm 25 years old again! 
I'm not believing this!” 
                          — Mr. Murphy, age 64, Lampart, IL.



Risk Free: Double Your Money Back Guarantee

If Herbal V does not give the desired results as stated
above, simply return the unused portion for a
double-your money back refund. No questions asked ! 

Order Now: Safe, Fast, Secure, Private

Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is
available only through this special promotional offer.
Herbal V arrives in plain packaging for your privacy.
Any and all information is kept strictly confidential.

Payment Methods

You may FAX or Postal Mail Checks, MasterCard, Visa,
& American Express.payments. Money Orders
are accepted only by Postal Mail. 


Each bottle of Herbal V contains 30 tablets, approximately
a 1 month supply.


Step 1: Place a check by your desired quanity.


______ 1 Bottle of Herbal V  $28


______ 2 Bottles of Herbal V $48


______ 3 Bottles of Herbal V $59


Please add $6 shipping and handling for any size order. 
[ Total cost including shipping & handling, 
1 bottle=$34, 2 bottles=$54, 3 bottles=$65 ]

International Orders
Please add $16 shipping and handling for any size order.
[ Total cost including shipping & handling,
1 bottle=$40, 2 bottles=$60, 3 bottles=$75 ]
We cannot accept foreign checks.
International money orders or credit cards only.

Step 2: Place a check by your desired payment method 
and complete fields if necessary.


_____Check or CHECK-BY-FAX [details below]


_____Money Order 


_____American Express 
Account Number__________________ Exp____/____

_____Visa
Account Number__________________ Exp____/____

_____MasterCard
Account Number__________________ Exp____/____


Please make your check or money order payable to
"Lion Sciences National".
 

Step 3: Please complete and print the following fields clearly.


Name ___________________________________________________ 


Address _________________________________________________


City ____________________________________________________ 


State ___________________________________________________ 


Zip _____________________________________________________ 


E-mail __________________________________________________ 


Signature _________________________________________________
[ required for check and credit card orders]



             Toll Free FAX Order Line: 1-800-940-6590
If faxing in your order, please state whether you require
a fax, email, or no confirmation at all. 
Allow up to one day for confirmation, if requested.
FAX orders are processed immediately.

  Or, print & mail to: LSN   
                       3502 N. Powerline Rd. #525 
                       Pompano Beach, FL 33069                


        ______________________________________________________


*CHECK BY FAX ORDERS: Complete the check as normal. Tape
the check in the area below. Below the check, clearly write
the check number, all numbers at the bottom of the check,
& your name. Tape the check below and fax the check to the
toll free FAX number above. Void the check. Our merchant
will electronically debit your account for the amount of 
the check; your reference number for this transaction will
be your check number. Nothing could be safer & easier !

                          TAPE CHECK BELOW















              _____________________________________________________________

This is a one time mailing: Removal is automatic and no further 
contact is necessary. Please Note: Herbal V is not intended to
diagnose, treat, cure or prevent any disease. As individuals differ,
so will results. Herbal V helps provide herbal and nutritional support
for male sexual performance. The FDA has not evaluated these 
statements. For details about our double your money back guarantee,
please write to the above address, attention consumer affairs 
department; enclose a self addressed stamped envelope for this and any 
requested contact information.
Thank You.


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA01334 for ietf-smime-bks; Fri, 3 Nov 2000 07:30:17 -0800 (PST)
Received: from mainserver.ps.gov.cn ([210.74.122.144]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA01329 for <[e-mail]>; Fri, 3 Nov 2000 07:30:14 -0800 (PST)
Date: Fri, 3 Nov 2000 07:30:14 -0800 (PST)
From: [e-mail]
Message-Id: <[e-mail]>
Received: from 1Cust239.tnt2.mia5.da.uu.net by mainserver.ps.gov.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id SXP0MWCJ; Fri, 3 Nov 2000 22:28:18 +0800
To: [e-mail]
Subject: At last, Herbal V, the all natural alternative to V----A!
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Herbal V: An Incredible All-Natural Healthy Alternative 


  Herbal V is the All Natural Approach to Male Virility,
  Vitality and Pleasure.



Available N o w ! 


Welcome to the New Sexual Revolution.

It's the all natural male potency and pleasure pill that men 
everywhere are buzzing about. Herbal V is safe, natural and
specifically formulated to help support male sexual function
and pleasure. You just take two easy-to-swallow tablets
one hour before sex. And there's more great news - you can
get Herbal V for less than $1 a pill.

Amazing word of mouth praise on Herbal V has been spreading 
like wildfire-already over 1,500,000 men  have chosen
Herbal V. Since it is 100% natural you will never have
to worry about safety. Try doctor-recommended Herbal V
today and have the greatest night of your life!


Herbal V... Bringing Back the Magic!


1,585,000 men can't be wrong. To date over 1 million men 
have tried the super supplement Herbal V.
Here is why: 

No Doctor Visit Required 
Available Over the Counter 
Not a Drug 
100% Natural 
Safe, No Worries 
Highest Quality Pharmaceutical-Grade Pure Nutriceuticals 
Guaranteed Potency & Purity 

Be a Real Man Again!

Questions and Answers

What is Herbal V?

Herbal V is a proprietary blend that was specifically
developed as a safe alternative for men who prefer
an all-natural approach to address impotence and boost
sexual performance. This amazing formula first became
popular with Hollywood insiders and the wealthy elite.
They were maximizing their sex lives, long before it 
was available to the general public. 

How does Herbal V work?

Developed by a team whose goal was to create the perfect 
all-natural aphrodisiac. Herbal V is the result of that
remarkable effort. The Herbal V formula contains a precise
blend of cutting edge pro-sexual nutrients from around
the world that provide nutritional support, making it
possible for a man to have a pleasurable sexual experience. 

What can Herbal V do for me?

Herbal V helps support male sexual function and 
pleasure in a safe and natural manner. Simply put, 
it can make your sex life incredible. 

Is Herbal V Safe?

One of the great things about Herbal V is that it is
not a drug. It is an incredible herbal dietary supplement
that provides nutritional support for male sexual function
and pleasure. One of the most comforting features of
Herbal V is that you never have to worry about safety. 

Herbal V: Safe - Natural - Exciting

Many have speculated that because Herbal V is so
popular with men, it must contain prescription drugs
or chemical components. Herbal V does not contain any 
elements or traces of any prescription drug. Herbal V 
is made using the world's most technologically advanced
state-of-the-art cold processing equipment to ensure
maximum purity. Herbal V has been independently analyzed
by the nation's premier testing facility to ensure purity,
quality and to end the rumors that, because it is so
popular, it must somehow be chemical. It is not.
Herbal V is natural - just as it says on the label.
Herbal V is simply fantastic! 

Herbal V: Ingredients

Yohimbe, saw palmetto, avena sativa, androstenedione,
guarana, taurine, siberian ginseng, tribulus terrestris. 
Tribulus Terrestis is certified to enhanced testosterone
levels by increasing Luteinzing hormone (LH) levels. 
Androstenedione which is a precursor to testosterone
unlocks bound testosterone and makes it biologically
active again quickly. This means a dramatic surge in 
desire. Avena Sativa Stimulates the neurotransmitter 
pleasure centers to maximum capacity. This greatly
intensifies pleasure.

Just listen to what Herbal V has done for the sex lives
of people like you!

“On a scale of 1 to 10, it's a 15. Electrifying. It's like 
a wonder pill!” 
— Justin Q B., New Haven, Texas

“I haven't had sexual relations in 11 years. Then with 
Herbal V it was... wow! It works again!” 
— Sid R., Lakeland, Florida

“I had sex four times in one night. It made me feel
like a 19-year-old again.” 
— Chip S, Beech Mountain, North Carolina

“Herbal V has turned my husband into a Sexual Superman! 
I like the fact that it's all natural and has no
side effects. It's bringing back the good old days.” 
— Jennifer B, Beverly Hills, California 

The above testimonials are from product literature, 
and we have not independently verified them.
However, the following testimonial is from a "senior"
gentleman who has purchased his second bottle of
Herbal V. When we heard his words with our own ears,
we asked his permission to print them here. 

 “Man! I'm wild as I can be! I feel like I'm 25 years old again! 
I'm not believing this!” 
                          — Mr. Murphy, age 64, Lampart, IL.



Risk Free: Double Your Money Back Guarantee

If Herbal V does not give the desired results as stated
above, simply return the unused portion for a
double-your money back refund. No questions asked ! 

Order Now: Safe, Fast, Secure, Private

Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is
available only through this special promotional offer.
Herbal V arrives in plain packaging for your privacy.
Any and all information is kept strictly confidential.

Payment Methods

You may FAX or Postal Mail Checks, MasterCard, Visa,
& American Express.payments. Money Orders
are accepted only by Postal Mail. 


Each bottle of Herbal V contains 30 tablets, approximately
a 1 month supply.


Step 1: Place a check by your desired quanity.


______ 1 Bottle of Herbal V  $28


______ 2 Bottles of Herbal V $48


______ 3 Bottles of Herbal V $59


Please add $6 shipping and handling for any size order. 
[ Total cost including shipping & handling, 
1 bottle=$34, 2 bottles=$54, 3 bottles=$65 ]

International Orders
Please add $16 shipping and handling for any size order.
[ Total cost including shipping & handling,
1 bottle=$40, 2 bottles=$60, 3 bottles=$75 ]
We cannot accept foreign checks.
International money orders or credit cards only.

Step 2: Place a check by your desired payment method 
and complete fields if necessary.


_____Check or CHECK-BY-FAX [details below]


_____Money Order 


_____American Express 
Account Number__________________ Exp____/____

_____Visa
Account Number__________________ Exp____/____

_____MasterCard
Account Number__________________ Exp____/____


Please make your check or money order payable to
"Lion Sciences National".
 

Step 3: Please complete and print the following fields clearly.


Name ___________________________________________________ 


Address _________________________________________________


City ____________________________________________________ 


State ___________________________________________________ 


Zip _____________________________________________________ 


E-mail __________________________________________________ 


Signature _________________________________________________
[ required for check and credit card orders]



             Toll Free FAX Order Line: 1-800-940-6590
If faxing in your order, please state whether you require
a fax, email, or no confirmation at all. 
Allow up to one day for confirmation, if requested.
FAX orders are processed immediately.

  Or, print & mail to: LSN   
                       3502 N. Powerline Rd. #525 
                       Pompano Beach, FL 33069                


        ______________________________________________________


*CHECK BY FAX ORDERS: Complete the check as normal. Tape
the check in the area below. Below the check, clearly write
the check number, all numbers at the bottom of the check,
& your name. Tape the check below and fax the check to the
toll free FAX number above. Void the check. Our merchant
will electronically debit your account for the amount of 
the check; your reference number for this transaction will
be your check number. Nothing could be safer & easier !

                          TAPE CHECK BELOW















              _____________________________________________________________

This is a one time mailing: Removal is automatic and no further 
contact is necessary. Please Note: Herbal V is not intended to
diagnose, treat, cure or prevent any disease. As individuals differ,
so will results. Herbal V helps provide herbal and nutritional support
for male sexual performance. The FDA has not evaluated these 
statements. For details about our double your money back guarantee,
please write to the above address, attention consumer affairs 
department; enclose a self addressed stamped envelope for this and any 
requested contact information.
Thank You.


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA08077 for ietf-smime-bks; Thu, 2 Nov 2000 11:49:48 -0800 (PST)
Received: from nl-imail01.cmg.nl (nl-mail-dmz.cmg-gecis.nl [195.109.155.100]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA08073 for <[e-mail]>; Thu, 2 Nov 2000 11:49:46 -0800 (PST)
From: [e-mail]
Received: FROM nl-iscan.cmg.nl BY nl-imail01.cmg.nl ; Thu Nov 02 20:46:17 2000 +0100
Received: FROM nl-amv-route01.cmg.nl BY nl-iscan.cmg.nl ; Thu Nov 02 20:38:28 2000 +0100
Received: from nl-irelay.cmg.nl (NL-IRELAY [10.16.67.60]) by nl-amv-route01.cmg.nl with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id WD5NS413; Thu, 2 Nov 2000 20:37:18 +0100
Received: from mail pickup service by nl-irelay.cmg.nl with Microsoft SMTPSVC; Thu, 2 Nov 2000 20:32:21 +0100
Received: from loki.ietf.org ([132.151.1.177]) by nl-irelay.cmg.nl with Microsoft SMTPSVC(5.0.2195.1600);	 Thu, 2 Nov 2000 16:02:18 +0100
Received: (from adm@localhost)	by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA26956	for [e-mail]; Thu, 2 Nov 2000 08:45:01 -0500 (EST)
Received: from ietf.org (odin.ietf.org [10.27.2.28])	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA26115	for <[e-mail]>; Thu, 2 Nov 2000 06:36:09 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16351;	Thu, 2 Nov 2000 06:36:08 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-symkeydist-02.txt
Date: Thu, 02 Nov 2000 06:36:07 -0500
X-OriginalArrivalTime: 02 Nov 2000 15:02:19.0402 (UTC) FILETIME=[E56DE6A0:01C044DD]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




--9B095B5ADSN=_01C044DC88685DA000000295nl?irelay.cmg.nl--


Received: by ns.secondary.com (8.9.3/8.9.3) id DAA03226 for ietf-smime-bks; Thu, 2 Nov 2000 03:29:46 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA03221 for <[e-mail]>; Thu, 2 Nov 2000 03:29:45 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16351; Thu, 2 Nov 2000 06:36:08 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-symkeydist-02.txt
Date: Thu, 02 Nov 2000 06:36:07 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--