Subject: Definition for DES-40
From: "Paul E. Hoffman" <[email-masked]>
To: [email-masked]
Date: Tue, 13 May 1997 15:27:46 -0700

Because we still haven't heard from RSA about the status of the "trade
secret" rights for RC2, some people have begun to explore alternatives. One
alternative that has come up is using DES wth a 40-bit key. Russ Housley
and I have just submitted a draft on how to create DES-40 keys from regular
56-bit DES keys. You can find it at
<http://www.imc.org/ietf-smime/draft-hoffman-des40>.

--Paul E. Hoffman, Director
--Internet Mail Consortium

Date: Mon, 12 May 1997 13:53:06 -0700
To: [email-masked]
From: "Paul E. Hoffman" <[email-masked]>
Subject: Re: Mime types and parameters for certs-only message
Sender: [email-masked]

At 12:08 PM -0700 5/12/97, Graham Finlayson wrote:
>Does this require a new mime type, (eg pkcs7-publish-request), or could
>this be embedded in the smime-type parameter proposed above. If it is to be
>embedded in a smime-type parameter, then certs-only is not specific enough.

I can see two possible solutions here:

a) smime-type=certs-only; cert-type={ publish | pksc10-response }

b) smime-type={ certs-only | cert-publish | pkcs10-response }

Of these two, I prefer (a), because it simplifies the decision process for
the sending agent who may not know why it is sending the cert. Also, (a)
would scale for the same kinds of responses information in non-S/MIME
environments.

--Paul E. Hoffman, Director
--Internet Mail Consortium

Date: Mon, 12 May 1997 12:08:25 -0700
To: Laurence Lundblade <[email-masked]>
From: Graham Finlayson <[email-masked]>
Subject: Re: Mime types and parameters for certs-only message
Cc: [email-masked]
Sender: [email-masked]

At 11:10 AM 5/12/97 -0700, Laurence Lundblade wrote:
>The current draft uses the MIME type application/pkcs7-mime for four
>different things: signed-only, enveloped-only, cert-only and
>signedAndEnveloped. There is no way from the MIME information to determine
>which a message might be. You have to parse the PKCS7 to find out.
>
>There are some reasons for bringing this information up to the MIME type
>level which I'll mention below. The basic reason is that MIME type
>information is already easily available in many implementations and it's
>widely used to invoke viewers, display icons, etc.  A very good example is
>IMAP where you can fetch the MIME information without the whole body.
>
>To make this available in the MIME type, I suggest adding a MIME parameter
>to the application/pkcs7-mime type. We can call it "smime-type", and it can
>have the four values I mentioned above. The nice thing about a parameter is
>that they are always ignored if not understood, thus nothing will break by
>its addition. The bad thing about a parameter is that many MIME
>implementations can switch viewers only on the MIME type, and not on the
>parameters. However I think introducing new MIME types at this point would
>be too traumatic.
>

Are the four values specified above a suitable abstraction. For example, if
I want to publish a certificate to an LDAP repository (or similar), I may
want to send a PKCS7 certs-only message, with the certificate to be
published. I would like the receiving application to know that this was a
certificate publish request, as opposed to a response to a PKCS10
certificate request.

Does this require a new mime type, (eg pkcs7-publish-request), or could
this be embedded in the smime-type parameter proposed above. If it is to be
embedded in a smime-type parameter, then certs-only is not specific enough.

Graham

Date: Mon, 12 May 1997 11:10:17 -0700
To: [email-masked]
From: Laurence Lundblade <[email-masked]>
Subject: Mime types and parameters for certs-only message
Sender: [email-masked]

The current draft uses the MIME type application/pkcs7-mime for four
different things: signed-only, enveloped-only, cert-only and
signedAndEnveloped. There is no way from the MIME information to determine
which a message might be. You have to parse the PKCS7 to find out.

There are some reasons for bringing this information up to the MIME type
level which I'll mention below. The basic reason is that MIME type
information is already easily available in many implementations and it's
widely used to invoke viewers, display icons, etc.  A very good example is
IMAP where you can fetch the MIME information without the whole body.

To make this available in the MIME type, I suggest adding a MIME parameter
to the application/pkcs7-mime type. We can call it "smime-type", and it can
have the four values I mentioned above. The nice thing about a parameter is
that they are always ignored if not understood, thus nothing will break by
its addition. The bad thing about a parameter is that many MIME
implementations can switch viewers only on the MIME type, and not on the
parameters. However I think introducing new MIME types at this point would
be too traumatic.

To give a few reasons why this is important:

If you subscribe to a CA service which e-mails you certs and crls for
people you're interested in you want to process those before you process
any of the signed messages. That way you'll find out that a cert was
revoked before you sign the contract just e-mail to you, rather than after.
By having the type info in the MIME type it's easier to process the
certs-only messages first.

The IMAP case is also interesting. IMAP users often want to optimize
bandwidth use by fetching only MIME parts that they need at the moment.
Thus an IMAP user that is missing their private key because they left their
smartcard in the last city might not want to download encrypted messages.
Without putting the type of message in the MIME type info, they can never
know the type without downloading the whole part.

A gateway may want to pre-check signatures on all incoming e-mail as a
service to people behind the gateway. Most gateways are MIME aware, but not
PKCS7 aware. They are more likely to invoke separate PKCS7 applications to
do the work. Thus having labeling in the MIME type will significantly
increase the efficiency of the gateway.

Another application may just want to display a different icon for different
MIME types as an aid to the user, and the application doing this should not
have to understand PKCS7.

I think one of the core reasons for having this sort general mechanism in a
spec we expect to be used for years in the future is that we can't think of
all the possibilities now. The cost to enable greater possibilities in the
future is small with features like this.

LL

To: [email-masked]
Subject: false alarm: dejanews has it after all
cc: [email-masked]
From: Keith Moore <[email-masked]>
Date: Mon, 12 May 1997 02:00:29 -0400
Sender: [email-masked]

Blake Ramsdell sent me private mail indicating that he found the
alleged rrc#2 source code on dejanews without any problem.
Silly me; since I had the message-id of the article I was
looking for, I assumed I could search for the article by message-id.
When I tried that, I found only the followups.  But as Blake
pointed out, clicking on the subject field of any of the message
goes to the entire thread, and the message I was looking for
was at the head of that thread.  I hadn't tried that.

Apparently DejaNews indexes articles by References, but not
by Message-Id.

I apologize for the false alarm and for jumping to the wrong conclusion.

Keith

(who is going on a badly needed vacation on Tuesday)

From: Keith Moore <[email-masked]>
cc: [email-masked]
to: [email-masked]
Subject: RRC.2 description missing from DejaNews
Date: Sun, 11 May 1997 22:40:11 -0400
Sender: [email-masked]

A few weeks ago, Peter Gutmann wrote:

> Do a DejaNews search for the subject "Specification for Ron Rivests Cipher 
> No.2" (I didn't call it RC2 :-) posted to sci.crypt on 11 Feb 1996, 
> message-ID <[email-masked]>.  

Last night, I decided to look at the rrc#2 algorithm in detail.
So I searched back through my personal ietf-smime mailing list archives
and found Peter's note, a portion of which is quoted above.
I then went to DejaNews to search for the aforementioned articles.

Neither article is there.  The followups are there, but not
the original articles.  I tried searching AltaVista also, but
didn't find the articles there either.

I leave it to list members to form their own conclusions.

Keith

From: Keith Moore <[email-masked]>
To: "Paul E. Hoffman" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Restarting the 40-bit debate 
Date: Sun, 11 May 1997 22:31:17 -0400
Sender: [email-masked]

> >I disagree.  If the standard claims to provide a certain degree of
> >privacy and authentication, but doesn't mandate that implementations
> >use cryptographic algorithms and key lengths sufficient to ensure
> >that degree of privacy or authentication, the standard has failed
> >to make good on its claims.
> 
> <sigh> Keith, for the nth time. Please stick to the spec. Please quote the
> spec. That's why we wrote it and are asking for comments.

The spec does claim to provide privacy and security.  

> S/MIME provides the following cryptographic security services for
> electronic messaging applications: authentication, message integrity
> and non-repudiation of origin (using digital signatures) and privacy
> and data security (using encryption)

I tend to believe that a spec should never say simply "this spec
provides security" because the question is one of degree.

> >Even with a longer key, I'd have to question whether the FOO
> >algorithm has received sufficient public review to make it the
> >only "MUST support" algorithm in the standard.
> 
> There is no FOO algorthim. The spec says there are multiple candidates for
> what it will be replaced with. Clearly, I thought.

Any algorithm chosen as part of the standard needs to have enjoyed
significant public review.

Keith

Date: Sat, 10 May 1997 21:44:57 -0700
To: [email-masked]
From: "Paul E. Hoffman" <[email-masked]>
Subject: Re: Restarting the 40-bit debate
Sender: [email-masked]

>Meta-discussion alert.

But a reasonable meta-discussion. Thank you for bringing it up.

The charter is languishing now because Jeff Schiller said that he won't
even consider this to become a working group until the RC2 secret and
S/MIME trademark issues are fully resolved. Personally, I agree with his
restrictions: they will lead to focus and clarity for the work. Jeff gave
RSA until July 1, and RSA said that they thought they would have a
resolution well before then.

At this time, neither of the two required issues is resolved, so talking
about a charter and a working group is premature. Well, I still believe
that a charter could be bounced around a bit, but I think it's premature to
go too far with it because there is still real doubt that we can be a WG.

What this leads to is us talking about drafts that may not end up coming
from a Working Group. The drafts might end up being Informational only. The
drafts might be prevented from being published in the IETF at all if they
include RC2 and RSA does not make the RC2 spec available in a reasonable
form. All of this was covered in glorious detail at the BOF in Memphis.

All of this is fine with me. I'm trying *not* to make it look like we're a
wannabe WG until it is clear that we *can* be a WG. Maybe I should take the
early proposed charter off the Web page, since it doesn't represent today's
reality.

What we're left with is a pair of drafts and a large group of people
wanting an open standard that is likely to be widely implemented. It is
certainly not a WG, there is no chairperson, there's just the drafts and
the current implementations that, to date, actually meet what the drafts
say (as long as you believe that FOO==RC2, which is yet to be seen). The
main questions to the *mailing list* are "does these drafts do what they
say that they do" and "are there technical or cryptographic flaws"; there
are lots of non-main questions. These questions will be relevant and useful
to the Internet community regardless of what the end result of the drafts
is, but these are not questions that relate to a stated charter.

Note to the folks on this list new to the IETF: No, this isn't picky IETF
politics. This is how good standards like many of the ones that the IETF
has promulgated are made. Ned's story about MIME is just one of many where
a very good product came out of a very hard process. There are lots of
similar stories within the IETF.

Is this the only way to move an open standard forward? No, but it works
better for the entire Internet community and the S/MIME implementors than
leaving S/MIME a closed, proprietary, poorly-worded "standard".

--Paul E. Hoffman, Director
--Internet Mail Consortium

Date: Sat, 10 May 1997 18:23:14 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Restarting the 40-bit debate
To: "Paul E. Hoffman" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Meta-discussion alert.

> > I disagree.  If the standard claims to provide a certain degree of
> > privacy and authentication, but doesn't mandate that implementations
> > use cryptographic algorithms and key lengths sufficient to ensure
> > that degree of privacy or authentication, the standard has failed
> > to make good on its claims.

> <sigh> Keith, for the nth time. Please stick to the spec. Please quote the
> spec. That's why we wrote it and are asking for comments.

Paul, I think this goes much too far. Frankly, my assessment is that Keith is
entirely justified in posting what he has. And more to the point, if his
discussion is out of order, so is discussion of the documents you want to have.

This is supposed to be an IETF WG or WG-to-be. Fine. This means the group first
has to get a list set up. A BOF is also useful at this point. Both of these
have already happened.

The next step is to come up with a charter. The beginnings of one were posted
to the list back in January. As far as I know it hasn't been approved -- I see
no signs of much discussion or approval of it on the list by the WG members,
and I see no signs of the charter or approval of it on the IETF home page. (In
fact I cannot find any trace of the S/MIME WG at all there. I don't even know
what IETF this group is being chartered in; I assume it's Security. I also
don't know who the chair of the group is -- the charter doesn't say and I
assume it's not Paul since he's editor of various documents. Having the WG
chair also be the editor has been shown over and over again to be a truly
terrible idea.) This really needs to be attended to before anything else is
done. There is little point in having WG discussion when the WG itself doesn't
exist and has no clearly defined purpose.

Now, the charter that was posted to the list is interesting. (It is also
nowhere near adequate, but that's another matter. Nor is it the same as the
draft charter on the Web page. In accordance with IETF rules, however, I take
the last draft posted to the list as the more definitive one. It certainly is
longer and more complete.) It basically says that the group has two jobs, one
to specify the message format and the other to come up with a "minimum security
profile" for S/MIME, with the latter being the "main task" of the WG. There is
no indication that these two tasks are to done in any particular order than the
deliverable dates, which put the profile second. In fact in practice it is
obvious that the two cannot be separated, as the message format must be
flexible enough to accomodate whatever minimum security profile is developed.
As such, I see considerable justification for discussing the profile first.

Now, I believe what Keith, myself, and others are discussing is what this
minimum security profile needs to be. (It certainly is what I've been trying to
discuss.) And if you believe this group's charter as posted is valid, then this
discussion is totally within the scope of this group. This is true even though
we don't reference your message specification document in everything we say or
discuss. I realize that you want to discuss the messaging specification first,
that you are frustrated that people are ignoring the document you worked so
hard to produce,  but I find nothing in the charter to support your position on
this, and as such I see no reason to be bound by your personal preferences in
this regard.

BTW, if you don't believe the charter will be approved with the stated tasks,
then yes, I agree this discussion is out of order, but then so is discussion of
the documents.

Let me also offer you a bit of advice based on my own past experience that I
think is roughly comparable. When Nathaniel and I first wrote the specification
for what eventually became MIME, our work was basically ignored by the WG for
well over a year. This was incredibly frustrating for us, but in hindsight the
WG chair had a point: Our specification was basically the second thing that
needed to be considered (even though it actually appeared first in the
charter), and the basic problem was that there wasn't enough time in a given
meeting to cover what needed to be done first. Eventually the situation got so
bad that the first matter (SMTP extensions) was split off to a second WG with a
different chair. (Where it bogged down for another year.) In retrospect
a better charter would have fixed this and saved tons of time -- another point
you should consider.

What both Nathaniel and I found to be true was that jumping up and down and
trying to get people to shift focus onto what concerned us didn't work. In fact
all it did was waste time on procedural points that could have been used on
technical matters. I would estimate that our poor handling of this situation
(mostly mine, actually) cost MIME at least four months. And I firmly believe
you're doing yourself no favors by emulating our past behavior in this new
context.

> Where in the spec does it "claim to provide a certain degree of privacy and
> authentication" that it does not meet?

Actually, the message specification should be silent on this point. The
security profile cannot be silent, and that is what we're effectively
discussing. And more to the point, there are also some tacit requirements
imposed by the IETF standards process itself. (More of them than before now
that the IAB security workshop is complete.) I believe it is this set of
(admittedly somwaht nebuluos) requirements that Keith is referring to. I know
it is what I have been referring to in my postings.

> Please cite a specific sentence or
> paragraph. We'll fix it, I promise. What we *do* promise in the spec is
> that if you use the minimum algorithm (FOO/40), you are using weak
> cryptography. We say that many, many times. Thus, we are living up to our
> claims. If you disagree, please state exactly where we have made a claim
> higher than we support.

> (Obviously, this request goes out to everyone. We do *not* want a spec that
> overstates its security.)

> >Even with a longer key, I'd have to question whether the FOO
> >algorithm has received sufficient public review to make it the
> >only "MUST support" algorithm in the standard.

> There is no FOO algorthim. The spec says there are multiple candidates for
> what it will be replaced with. Clearly, I thought.

I for one haven't read the updated specifications. I see no reason to until the
discussion of what is going to be specified in the first place is finished and
a consensus emerges. Only then will I know what to look for in the documents.

If you want to try and track this consensus and keep the documents updated
that's all well and good, but to be honest I think you're making unnecessary
work for yourself at this stage in the game.

				Ned

Date: Sat, 10 May 1997 18:02:44 -0700
To: [email-masked]
From: "Paul E. Hoffman" <[email-masked]>
Subject: Re: Restarting the 40-bit debate
Sender: [email-masked]

At 4:03 PM -0700 5/10/97, Keith Moore wrote:
>I disagree.  If the standard claims to provide a certain degree of
>privacy and authentication, but doesn't mandate that implementations
>use cryptographic algorithms and key lengths sufficient to ensure
>that degree of privacy or authentication, the standard has failed
>to make good on its claims.

<sigh> Keith, for the nth time. Please stick to the spec. Please quote the
spec. That's why we wrote it and are asking for comments.

Where in the spec does it "claim to provide a certain degree of privacy and
authentication" that it does not meet? Please cite a specific sentence or
paragraph. We'll fix it, I promise. What we *do* promise in the spec is
that if you use the minimum algorithm (FOO/40), you are using weak
cryptography. We say that many, many times. Thus, we are living up to our
claims. If you disagree, please state exactly where we have made a claim
higher than we support.

(Obviously, this request goes out to everyone. We do *not* want a spec that
overstates its security.)

>Even with a longer key, I'd have to question whether the FOO
>algorithm has received sufficient public review to make it the
>only "MUST support" algorithm in the standard.

There is no FOO algorthim. The spec says there are multiple candidates for
what it will be replaced with. Clearly, I thought.

--Paul E. Hoffman, Director
--Internet Mail Consortium

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: Restarting the 40-bit debate 
Date: Sat, 10 May 1997 19:12:12 -0400
Sender: [email-masked]

> We could end the 40 bit debate and settle the interoperability
> issue by mandating RC4-128, IDEA, DES-EDE3, or DESX.

yes, lets.

Keith

From: Keith Moore <[email-masked]>
To: "Paul E. Hoffman" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Restarting the 40-bit debate 
Date: Sat, 10 May 1997 19:03:04 -0400
Sender: [email-masked]

> >  Furthermore, the latter
> >question is not terribly relevant, and addressing that question
> >diverts attention from more important issues.
> 
> Huh? Not terribly relevant? Any spec that forces weak cryptography should
> be rejected out of hand. 

I agree, of course, and I'd be surprised if there were any significant
support for a spec that did support weak cryptography.  That's why
I didn't think the question was relevant.

I understand now that you were asking whether your clarification 
of this in the latest draft was adequate.

> >The questions to ask are more on the order of:
> >
> >a. Will the protocol do what it claims to do?
> >   (e.g. does it really provide assurances of authentication and/or
> >   privacy?)
> 
> Good question, and I say the answer is yes on both. No one has said otherwise.

I disagree.  If the standard claims to provide a certain degree of 
privacy and authentication, but doesn't mandate that implementations 
use cryptographic algorithms and key lengths sufficient to ensure 
that degree of privacy or authentication, the standard has failed
to make good on its claims.

> >b. Will it provide adequate security for general-purpose use?
> >   (and if not, what is the intended scope of use, and is that
> >   scope sufficiently broad to warrant Internet standards-track
> >   approval?)
> 
> Another good question, and again I say yes. The only time that weak
> encryption is mandated is if all of the following conditions are met; in
> any other case, strong encryption can be used. 

If an implementation can fail to implement encryption of adequate
strength for general-purpose use and still claim to conform to the 
standard, the standard isn't providing adequate security.  

In the current draft, the only required encryption algorithm is 
the "FOO" algorithm with a key size of 40 bits.  This is inadequate 
for general purpose use.  

Even with a longer key, I'd have to question whether the FOO 
algorithm has received sufficient public review to make it the 
only "MUST support" algorithm in the standard.

Keith

From: Keith Moore <[email-masked]>
To: Bill Wohler <[email-masked]>
cc: Keith Moore <[email-masked]>, David Gaon <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Re[2]: Restarting the 40-bit debate 
Date: Thu, 08 May 1997 21:01:01 -0400
Sender: [email-masked]

  If I whisper sweet nothings to my wife in an email message, one bit
  is sufficient to keep the casual voyeur without tools from viewing
  the message in a readable spool area on a badly managed site.  That
  would be good enough for me.  (I suppose base64 would do the same
  thing ;-).

but as soon as the one-bit encryption is standardized, such voyeurs
will instantly have tools to make it easy for them to view such
messages.  and as you point out with your base64 example, if all 
you want to do is raise the bar very slightly, many existing 
tools do this.  rot13 is useful, but I wouldn't call it a privacy 
mechanism.

my personal experience is that even causal attackers (i.e. hobbyists
doing it for fun and/or minor malice) are willing and able to spend 
O(thousands) of cpu-hours on garden-variety workstations to defeat 
security systems (e.g. dictionary attacks on encrypted password 
files), not to mention the time spent developing the cracking tools.  

Keith

To: Keith Moore <[email-masked]>
cc: David Gaon <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Re[2]: Restarting the 40-bit debate
Date: Thu, 08 May 1997 17:26:22 -0700
From: Bill Wohler <[email-masked]>
Sender: [email-masked]

Keith Moore <[email-masked]> writes:
> guess it depends on how valuable the data is.

  Exactly.

  If I whisper sweet nothings to my wife in an email message, one bit
  is sufficient to keep the casual voyeur without tools from viewing
  the message in a readable spool area on a badly managed site.  That
  would be good enough for me.  (I suppose base64 would do the same
  thing ;-).

  Is this use relevant for the spec to cover?

Bill Wohler <[email-masked]>
Say it with MIME.  Maintainer of comp.mail.mh and news.software.nn FAQs.
If you're passed on the right, you're in the wrong lane.

From: Dennis Glatting <[email-masked]>
Date: Thu,  8 May 97 17:28:19 -0700
To: [email-masked]
Subject: Re: Restarting the 40-bit debate
Reply-To: [email-masked]
Sender: [email-masked]

Why focus on 40 bit crypto? Heck, France doesn't allow
encryption at all. By mandating 40 bit crypto are we
discriminating against the French? Why not argue over no
encryption as the minimal interoperable standard? The 40 bit
issue, from a technical perspective, seems silly. From a
commercial perspective I agree with Ned Freed, re credibility.

We could end the 40 bit debate and settle the interoperability
issue by mandating RC4-128, IDEA, DES-EDE3, or DESX.

-dpg

Date: Thu, 8 May 1997 17:15:04 -0700
To: [email-masked]
From: "Paul E. Hoffman" <[email-masked]>
Subject: Re: Re[2]: Restarting the 40-bit debate
Sender: [email-masked]

At 4:40 PM -0700 5/8/97, Keith Moore wrote:
>somehow I don't view s/mime as being likely to be used in
>broadcast media like usenet or mailing lists.

Well, in the case of mailing lists, you're clearly in disagreement with
many people here. Companies are already writing mailing list managers that
can handle S/MIME and PGP/MIME (and PEM...) for incoming and outgoing mail.
Yes, this is a hard problem with lots of tricky aspects; yes, it is
strongly desired in many communities. I see nothing in S/MIME or PGP/MIME
that prevents their use in mailing lists that can't be overcome.

>  I had the idea
>that it's primary intended purpose was to provide privacy,
>authentication, non-repudiation, etc for interpersonal mail.

Then you didn't read Section 1 of the draft very well. It explicitly states
that S/MIME is inteded for interpersonal mail *AND* non-mail transports
*AND* automated mail transfer agents. I know of developers who are working
in each area.

I believe for all significant applications, FOO/40 as described in Section
2.6 will never get used unless it is explicitly desired by both parties.
Period. If there is some way for me to rewrite Section 2.6 to make this
more painfully obvious than it is now, please suggest wording here.

For valuable data, either the sender will have previous knowledge of the
recipient's capabilities from previous interactions, or the sender will
risk failed decryption on the first try by using tripleDES. The chance that
an individual would send valuable information that absolutely must be
decrypted to someone they do not know the decryption capabilities of seems
highly remote. The chance that an automated system would do so borders on
the absurd. Both might send non-valuable information that could be subject
to a brute-force attack, but no one who understands the value of their data
would purposely use weak encryption on valuable data.

(And, yes, there are plenty of people who don't understand the value of
their data or the security of the Internet. Because we have not come up
with a standard that has attracted much deployment, these people are still
using the most popular form of security, cleartext.)

--Paul E. Hoffman, Director
--Internet Mail Consortium

From: Keith Moore <[email-masked]>
To: Bill Wohler <[email-masked]>
cc: Keith Moore <[email-masked]>, David Gaon <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Re[2]: Restarting the 40-bit debate 
Date: Thu, 08 May 1997 19:40:06 -0400
Sender: [email-masked]

> > Since you're playing devil's advocate...would one bit really be
> > sufficient for data mining?
> 
>   Probably not, but 40 bits most certainly is.

guess it depends on how valuable the data is.

granted, it wouldn't take many encryption bits to make data mining 
of usenet completely pointless...

somehow I don't view s/mime as being likely to be used in
broadcast media like usenet or mailing lists.  I had the idea
that it's primary intended purpose was to provide privacy, 
authentication, non-repudiation, etc for interpersonal mail.

Keith

To: Keith Moore <[email-masked]>
cc: David Gaon <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Re[2]: Restarting the 40-bit debate
Date: Thu, 08 May 1997 16:30:08 -0700
From: Bill Wohler <[email-masked]>
Sender: [email-masked]

Keith Moore <[email-masked]> writes:
> Since you're playing devil's advocate...would one bit really be
> sufficient for data mining?

  Probably not, but 40 bits most certainly is.

Bill Wohler <[email-masked]>
Say it with MIME.  Maintainer of comp.mail.mh and news.software.nn FAQs.
If you're passed on the right, you're in the wrong lane.

Date: Thu, 8 May 1997 15:03:54 -0700
To: [email-masked]
From: "Paul E. Hoffman" <[email-masked]>
Subject: Re: Restarting the 40-bit debate
Sender: [email-masked]

Thank you for making an effort to stay on topic.

At 1:38 PM -0700 5/8/97, Keith Moore wrote:
>> Is there something wrong with the spec? Does it force weak
>> cryptography?
>
>I realize you're trying to keep the flames down, but let me suggest
>that these two questions are not equivalent.

I didn't mean to indicate that they were equivalent. In fact, they are
clearly two very different questions, and I want answers to both of them.

>  Furthermore, the latter
>question is not terribly relevant, and addressing that question
>diverts attention from more important issues.

Huh? Not terribly relevant? Any spec that forces weak cryptography should
be rejected out of hand. There were earlier assertions on this list that
the spec forced people to use weak cryptography. I believe those assertions
are false, and tried as hard as possible to word the section so that
everyone could see that it doesn't force weak cryptography.

>The interesting question is not "Does the spec force weak cryptography?"

I disagree. This is a vitally important question.

>The questions to ask are more on the order of:
>
>a. Will the protocol do what it claims to do?
>   (e.g. does it really provide assurances of authentication and/or
>   privacy?)

Good question, and I say the answer is yes on both. No one has said otherwise.

>b. Will it provide adequate security for general-purpose use?
>   (and if not, what is the intended scope of use, and is that
>   scope sufficiently broad to warrant Internet standards-track
>   approval?)

Another good question, and again I say yes. The only time that weak
encryption is mandated is if all of the following conditions are met; in
any other case, strong encryption can be used. The set of qualifications
for being forced to use weak encryption are:

- A willingness on the part of the sender to use weak encryption
- No knowledge on the sender's part of the recipient's encryption capabilities
- An absolute unwillingness to risk decryption on the message

The combination of the last two says something to the effect of: "I don't
know you, but somehow I know that you use S/MIME. Even though we've had no
previous authenticated S/MIME interaction, I want to send you a secret
message that you must be able to decrypt on the first try, and I'm willing
to use weak cryptography to do it because I know that you might only be
capable of using weak cryptography as well."

As you can tell, this a highly limited case and not terribly likely in
human-to-human email environments. It requires some pretty odd out-of-band
knowledge: you know that the recipient is running S/MIME but you don't know
the recipient's capabilities. This means that you somehow know that they
are running S/MIME even though you've never gotten a signed or encrypted
message from them. *And* you want to send them a piece of encrypted mail
that they must be able to decrypt.

In all other cases, you will have knowledge of the recipient's capabilities
and you can use that knowledge to send the strongest encryption possible.

So, yes, it will provide adequate security for general-purpose use. In
fact, it will provide *strong* security for general-purpose use.

--Paul E. Hoffman, Director
--Internet Mail Consortium

From: Keith Moore <[email-masked]>
To: Bill Wohler <[email-masked]>
cc: Keith Moore <[email-masked]>, David Gaon <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Re[2]: Restarting the 40-bit debate 
Date: Thu, 08 May 1997 16:47:26 -0400
Sender: [email-masked]

> I suspect we're going to need some minimum value of n.

  On the other hand, one bit would be sufficient to prevent data
  mining.  This may actually have some general use in Usenet, for
  example.  Mind you, I'm just playing the devil's advocate here or
  trying to color outside the lines (and especially changing the
  subject ;-).

Since you're playing devil's advocate...would one bit really be
sufficient for data mining?  Or does it just mean that the data miners
first have to break the one-bit encryption?

Keith

From: Keith Moore <[email-masked]>
To: [email-masked] (David P. Kemp)
cc: [email-masked], [email-masked]
Subject: Re: Restarting the 40-bit debate 
Date: Thu, 08 May 1997 16:44:42 -0400
Sender: [email-masked]

> You seem to be of the opinion that the IETF policy is to promulgate
> standards that will not be commercially successful.  

I'm not going to dignify that with a response.

> You seem to be of the opinion that "quality" is a one-dimensional
> attribute, viz:
> 
>    "However, I sincerely doubt that something as weak as 40 bits can be
>     considered of sufficient quality for the Internet standards
>     track."

Quality isn't the only dimension for locks either.  But most people
would agree that locks need a certain minimum degree of quality to be
effective.

> The statement
> 
>    "You also seem to be of the opinion that US companies are
>     somehow "members" of IETF."
> 
> is mere sound-bite rhetoric, containing more heat than light.

I don't know about the participants in this group, but there are
apparently some misconceptions in other circles that IETF is a vendor
trade organization.  I'm trying to correct those misconceptions
wherever I find them.

Keith

From: Keith Moore <[email-masked]>
To: "Paul E. Hoffman" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Restarting the 40-bit debate 
Date: Thu, 08 May 1997 16:38:10 -0400
Sender: [email-masked]

> Is there something wrong with the spec? Does it force weak
> cryptography?

Paul, 

I realize you're trying to keep the flames down, but let me suggest
that these two questions are not equivalent.  Furthermore, the latter
question is not terribly relevant, and addressing that question
diverts attention from more important issues.

The interesting question is not "Does the spec force weak cryptography?"

The questions to ask are more on the order of:

a. Will the protocol do what it claims to do?
   (e.g. does it really provide assurances of authentication and/or
   privacy?)

b. Will it provide adequate security for general-purpose use?
   (and if not, what is the intended scope of use, and is that
   scope sufficiently broad to warrant Internet standards-track
   approval?)

Keith

To: Keith Moore <[email-masked]>
cc: David Gaon <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Re[2]: Restarting the 40-bit debate
Date: Thu, 08 May 1997 11:24:19 -0700
From: Bill Wohler <[email-masked]>
Sender: [email-masked]

Keith Moore <[email-masked]> writes:
> I suspect we're going to need some minimum value of n.

  On the other hand, one bit would be sufficient to prevent data
  mining.  This may actually have some general use in Usenet, for
  example.  Mind you, I'm just playing the devil's advocate here or
  trying to color outside the lines (and especially changing the
  subject ;-).

Bill Wohler <[email-masked]>
Say it with MIME.  Maintainer of comp.mail.mh and news.software.nn FAQs.
If you're passed on the right, you're in the wrong lane.

From: Keith Moore <[email-masked]>
To: Bill Wohler <[email-masked]>
cc: David Gaon <[email-masked]>, [email-masked], Keith Moore <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Re[2]: Restarting the 40-bit debate 
Date: Thu, 08 May 1997 14:17:32 -0400
Sender: [email-masked]

  Given the rapidly increasing power of computing power, it may be
  futile to specify any number of bits in the spec.  Perhaps we should
  replace all the n-bit language with something like:

    A compliant agent will generate or accept n-bit keys, where n is
    an arbitrary number determined by protocol or out of band by the
    interested parties.

I suspect we're going to need some minimum value of n.

From: Keith Moore <[email-masked]>
To: "David Gaon" <[email-masked]>
cc: [email-masked], Keith Moore <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Re[2]: Restarting the 40-bit debate 
Date: Thu, 08 May 1997 14:16:50 -0400
Sender: [email-masked]

     Whether you like it or not, and whether you want to believe it or not, 
      these individual contributors to the IETF and its proceedings DO 
     REPRESENT their companies and the best interests of their companies,  
     AND NOT NECESSARILY THE BEST INTERESTS OF THE INTERNATIONAL USER 
     COMMUNITY.

Companies may believe they are sending representives to IETF, but 
IETF policy is to recognize only individuals.  The individuals who 
contribute to IETF engineering work bear full responsibility for their 
technical recommendations, regardless of their companies' policy.

Keith 

To: David Gaon <[email-masked]>
cc: [email-masked], Keith Moore <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Re[2]: Restarting the 40-bit debate
Date: Thu, 08 May 1997 11:09:18 -0700
From: Bill Wohler <[email-masked]>
Sender: [email-masked]

Folks,

  Can we please not have any more notes that have nothing to do with
  the spec?  Thanks.

  Now for something completely different:

  Given the rapidly increasing power of computing power, it may be
  futile to specify any number of bits in the spec.  Perhaps we should
  replace all the n-bit language with something like:

    A compliant agent will generate or accept n-bit keys, where n is
    an arbitrary number determined by protocol or out of band by the
    interested parties.

Bill Wohler <[email-masked]>
Say it with MIME.  Maintainer of comp.mail.mh and news.software.nn FAQs.
If you're passed on the right, you're in the wrong lane.

Date: Thu, 08 May 97 13:19:50 EST
From: "David Gaon" <[email-masked]>
To: [email-masked], Keith Moore <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re[2]: Restarting the 40-bit debate 
Sender: [email-masked]

          Keith
          
          You said:
          
          >>Companies, whether they're based the United States or 
          otherwise, don't participate in IETF working groups.  Individuals 
          do.  Those individuals cannot be assumed to represent the 
          companies they work for, and at any rate, IETF doesn't recognize 
          such representation.<<
     
     You are playing ostrich here.
     Whether you like it or not, and whether you want to believe it or not, 
      these individual contributors to the IETF and its proceedings DO 
     REPRESENT their companies and the best interests of their companies,  
     AND NOT NECESSARILY THE BEST INTERESTS OF THE INTERNATIONAL USER 
     COMMUNITY.
     
     David Gaon

          

Date: Thu, 8 May 1997 08:43:26 -0700
To: [email-masked]
From: Laurence Lundblade <[email-masked]>
Subject: comments on the draft, 8bit & binary issues
Sender: [email-masked]

The current draft allows the transfer encoding on the secured MIME entities
to be 8bit or binary. We've talked about this before, but I'd like to raise
the issue again because I think it's probably not the right way of doing it
and I'm not sure we've discussed all the points below.

I think it's important to separate the binary discussion from the 8bit
discussion because there reasons for doing one or the other are quite
different. Note also these points are raised for igning and enveloping with
application/pkcs7-mime, not multipart signed. Multipart-signed must be 7bit
as defined by RFC-1847.

Allowing 8bit text mostly avoids the use of quoted-printable/unreadable
which is a big issue outside the US. It forces non-USASCII characters to be
transfer encoded in a way that makes them less readable than just having
the bit stripped (or so I understand).

The disadvantage of allowing 8bit text is that in some cases you can't
remove a layer of security and forward the message on without changing it.
There's no way for the original sender to know what transports the message
might be relayed in at a later time. The only safe assumption is 7bit.

I would suggest that anyone that can unwrap an application/pcks7-mime
message has the ability to transfer decode it. Thus the "quoted-unreadable"
argument doesn't apply.

The big point in favor of allowing binary is that it saves space by
avoiding the layer of base64 on the inside parts in addition to the base64
encoding of the BER encoded PCSK-7 object.

I would argue that a factor against allowing binary MIME is difficulty of
implementation.  I recall in previous discussion that we thought binary was
OK because other transport such as HTTP uses it.  However, nested multipart
objects are not used on the web, and that's when the implementation becomes
more difficult.  It's certainly not impossible, but it will burden many
MIME processors that exist today. There are also mail stores that cannot
store binary MIME in common use today.

Another argument against binary lack of forwardability for unknown
transport as mentioned above in regards to 8bit text.

Last, I think having the same transfer encoding requirements, no matter the
signing or enveloping format is a desirable thing leading to a simpler
standard and simpler implementations and guaranteed forwardability. The
primary cost is the increased size for secured binary objects.

LL

Date: Thu, 8 May 1997 10:43:22 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Restarting the 40-bit debate
Sender: [email-masked]

> From: Keith Moore <[email-masked]>
>
> You seem to be of the opinion that IETF exists to provide market
> opportunities to US companies.  You also seem to be of the opinion
> that US companies are somehow "members" of IETF.  Finally, you seem
> to believe that IETF's mission is to endorse the Clinton administraton's
> cryptography policy by developing standards which are consistent with
> that policy.

You seem to be of the opinion that the IETF policy is to promulgate
standards that will not be commercially successful.  PEM, for example
was a well designed mechanism from a security point of view, but failed
because it was not flexible enough to accommodate the needs of its users.

You seem to be of the opinion that "quality" is a one-dimensional attribute,
viz:

   "However, I sincerely doubt that something as weak as 40 bits can be
    considered of sufficient quality for the Internet standards track."

That's like saying Consumer Reports quality ratings for cars depends only
on horsepower.  Certainly more is better, but claiming that a 1.8L BMW is
of poorer quality than a 4.3L Cavalier is counter-intuitive.  There is more
than one dimension to be considered.

I would argue that "widespread deployment" is one of the more important
quality criteria for IETF standards.  I believe that John Gilmore, who is no
fan of the U.S. Government, would agree - his cryptowall proposal accepted
unauthenticated keys as the tradeoff for achieving actual usage.

The statement

   "You also seem to be of the opinion that US companies are
    somehow "members" of IETF."

is mere sound-bite rhetoric, containing more heat than light.

No one, certainly not Blake, is under the misapprehension that the IETF
has a membership roster or that companies, governments, or universities,
US or otherwise, are enrolled as members.  Individuals who contribute to
the IETF, including the S/MIME working group if it eventually exists,
represent their own interests.  Those interests may or may not be
highly correlated with the interests of their employers/affiliates. I would
expect that the smaller the organization, the tighter the correlation.
Small software developers should have a particularly strong interest in
ensuring that whatever standards they labor to develop will result in
increased sales for their companies.

Academics, for good or ill, don't have the same incentives.  So feel free
to contribute to the process, but please refrain from denigrating the
motives of the rest of the participants.

To: [email-masked]
Subject: comments on draft-dusse-smime-msg
cc: [email-masked]
From: Keith Moore <[email-masked]>
Date: Wed, 07 May 1997 22:44:43 -0400
Sender: [email-masked]

Any usable encryption protocol must specify at least one strong 
MUST IMPLEMENT encryption algorithm.  (I would define this as
one algorithm that has not been broken using only knowledge of
the algorithm used and the ciphertext).  If there is no MUST
IMPLEMENT algorithm, it fails the interoperability requirement.
If the only MUST IMPLEMENT algorithms are weak ones, the
protocol isn't technically sound -- it fails to provide 
the service that it claims to provide.

As far as I know, DES-EDE3-CBC/tripleDES is sufficiently strong,
but the current draft says only "SHOULD implement".   This is 
not sufficient. 

Engineering standards for bridge design do not allow designs 
that are known to collapse under load.  Neither should IETF approve 
an encryption standard that is known to be easily breakable.

Keith

Date: Thu, 8 May 1997 02:33:35 GMT
CC: [email-masked]
From: Lindsay Mathieson <[email-masked]>
Subject: RE: Restarting the 40-bit debate
To: Blake Ramsdell <[email-masked]>
Sender: [email-masked]

>I'm certainly not trying to make some political statement about 
>"America
>is superior to all other countries" -- certainly in the international
>cryptographic game we're not.

I didn't think you where. What I thought you where saying is that the it
would be good for everyone if the standard allowed weak 40 bit encryption so
that US companies could export.
--
Lindsay Mathieson
Black Paw Communications
	http://www.blackpaw.com/

Date: Thu, 8 May 1997 02:32:55 GMT
CC: [email-masked]
From: Lindsay Mathieson <[email-masked]>
Subject: RE: Restarting the 40-bit debate
To: "Paul E. Hoffman" <[email-masked]>
Sender: [email-masked]

>Keith, Lindsay, and yes, even Blake: get back on topic. There is work 
>to be
>done here. Arguing about what's best for US industry, why US laws are 
>bad,
>and so on, IS A WASTE OF OUR TIME HERE. Looking carefully at the spec 
>and
>making sure it does not mandate weak cryptography is part of the work 
>at
>hand.

Fair enough - noted. I'll keep my mouth shut re politics et al from now on.
My apologies for "knee jerking" (it was 6am here!)

40 bit encryption as a "MAY" or "SHOULD" is fine be me anyway.
--
Lindsay Mathieson
Black Paw Communications
	http://www.blackpaw.com/

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: Keith Moore <[email-masked]>, Blake Ramsdell <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Restarting the 40-bit debate 
Date: Wed, 07 May 1997 21:22:31 -0400
Sender: [email-masked]

> At the last IETF a presentation was given showing IETF meeting
> attendance verses location. When meetings were held outside
> of North America attendance was low. In San Jose, attendance
> was high. Both lows and highs were compared against meetings
> held in other North American cities. I suspect from that data,
> my own meeting attendance, and cursory examination of
> previous "IETF MAILING: REGISTERED ATTENDEES" mail
> messages, American companies do compose a substantial
> percentage of IETF participants.

Companies, whether they're based the United States or otherwise, 
don't participate in IETF working groups.  Individuals do.  
Those individuals cannot be assumed to represent the companies
they work for, and at any rate, IETF doesn't recognize such 
representation.

And while there are indeed many IETF participants from the United 
States, there is no reason to assume that anything remotely 
resembling a consensus of those participants, support the 
interests of US companies that want to export weak cryptography.

> The IETF may not endorse crypto policies such as the US
> Government's but those policies do have an impact on the work
> coming out of the IETF. For example, TLS includes 40 bit crypto.
> The GSS-API SESAME mechanism proposal includes 40 bit crypto.
> The IPsec group made the 56 bit DES-CBC ESP transform mandatory
> to make a political statement to the United States government
> and to encourage US companies to put pressure on the government
> to relax export restrictions; however, a 40 bit ESP transform
> draft was recently submitted.

All of the examples you give are merely proposals.  
None of them has been approved for the Internet standards track.

> S/MIME, I remember reading in a
> document from RSA's Web site, includes 40 bit crypto due to US
> export restrictions and the desire to have an international
> interoperabe base, though S/MIME is not an IETF standard.

S/MIME is not a standard in any formal sense -- that's just a 
term that RSA likes to use to encourage people to buy in to it.
Even calling it a de facto standard would be a stretch.
If S/MIME is a standard, so is PGP.

Keith

Date: Wed, 07 May 1997 15:00:50 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: RE: Restarting the 40-bit debate
To: Blake Ramsdell <[email-masked]>
Cc: "'Keith Moore'" <[email-masked]>, "'Paul E. Hoffman'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Sender: [email-masked]

I normally partipate in these discussions as a member of the IETF. I'm going to
depart from that position in this posting and answer as an Innosoft corporate
officer and employee.

> > I don't believe this.  First, there are many factors involved besides
> > US export rules -- including the existance of patents and the
> > licensing practices of certain firms.  PGP has a reputation which
> > gives it credibility in certain circles and undermines its credibility
> > in others.  Second, people are shipping strong encryption products
> > both inside and outside the United States.

> I think the point is that within the domain of US commercial for-profit
> software companies, strong-encryption-only specs are only going to
> appeal to those companies that don't consider their international sales
> to be important.

I disagree and I offer the company I work for, Innosoft, as a counterexample.
Innosoft currently implements and sells email products internationally. About
45% of our sales and revenues are non-US. We have numerous international
distributors and we expend considerable effort as a company working with them.
As such, I take it as given that we regard international sales as extremely
important.

Now, as it happens Innosoft also implements strong encryption services for
email (not S/MIME -- this is SASL based transport level stuff) with no
provisions for key escrow and no plans to ever add such provisions, which of
course we then can only sell to the domestic subset of our customer base.

We do not implement weak encryption or key escrow services and have no
intention of doing so -- such services simply do not appeal to us as a possible
product offering. I suppose we might consider adding them if we had a direct
request from an international customer to do so and the customer was fully
aware of the consequences of their use, but I've yet to encounter a customer
that meets these criteria.

> In my opinion, these companies are missing out on a large market that
> wants products.  We have a large customer base that is non-US,
> non-Canada and I certainly don't consider ourselves to be the largest
> company out there (which means that the Apples, IBMs and Microsofts of
> the world are much more interested in this market than I am).

Our assessment of our customer base is that they are a pretty savvy lot. They
absolutely do want encryption products, in fact they want them desperately and
they hammer on us constantly to provide them, but they aren't interested in
products that only implement weak encryption. And they absolutely do know the
difference -- I'm sorry, but I've worked on far too many RFPs that demonstrate
such knowledge in abundance to believe otherwise. In fact it's hard enough
trying to sell our domestic customers on strong encryption after they've read
somewhere that such-and-such or so-and-so has been compromised, let alone weak
encryption where every week it seems there's another result showing how easy it
is in practice to break.

The best we could hope for were we to offer weak encryption internationally
would be for them to dismiss us as naive fools. A more likely outcome,
unfortunately, would be for them to reassess us as knaves trying to sell them a
pig in a poke. Either way it falls out this isn't an acceptable tradeoff for
us. I suppose we might win in the short term with our less informed customers
but we'd lose in the long run, because people have a way of finding these
things out. And besides, we have a high degree of committment to our customers
to provide them with the best technology that's available, and weak encryption
does exactly qualify here. 

My view of standards requiring weak crypto is that they are simply a last-ditch
attempt to generate credibility for these sorts of solutions in the marketplace
so that US companies can sell inadequate products to international clientele.
Unfortunately the lack of credibility of such solutions is inherent in the
solutions themselves so no amount of standards sanction is going to help. In
the end all such sanctioning will do is cause a loss of credibility in the
standards process itself.

The long and short of it is that US manufacturers have been boxed in by the
actions of the US government, and the idea that standards will make weak
encryption acceptable is really nothing but wishful thinking. This I believe to
be the cold, hard, reality, a situation I estimate is costing Innosoft around
half a million dollars a year at the present time in lost revenue (more as we
continue to grow, of course), and also a situation that our offering weak
encryption products won't change appreciably. And while I (naturally) have
enormous sympathy for other companies caught in the same bind as we are, this
doesn't mean I'm willing to ignore the evidence of my own experience and
endorse the use of weak encryption in standards track documents. My sincere
belief is that this is simply not in my company's best interest. (I've argued
elsewhere with my IETF hat on that it isn't in the IETF's best interest
either.)

> It seems that US companies with an interest in international sales may
> be a large faction of the overall IETF membership, but I might be wrong.

I suspect you are quite right in your demographics of the participants here,
but as my example shows, your assessment of what necessarily follows from this
isn't right in at least one case that I have knowledge of.

				Ned

From: Dennis Glatting <[email-masked]>
Date: Wed,  7 May 97 17:08:07 -0700
To: Keith Moore <[email-masked]>
Subject: Re: Restarting the 40-bit debate 
cc: Blake Ramsdell <[email-masked]>, "[email-masked]'" <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

From: Keith Moore <[email-masked]>
Date: Wed, 07 May 1997 17:40:16 -0400

> > I think the point is that within the domain of US commercial for-profit
> > software companies, strong-encryption-only specs are only going to
> > appeal to those companies that don't consider their international sales
> > to be important.
> >
> > In my opinion, these companies are missing out on a large market that
> > wants products.  [...]
> >
> > It seems that US companies with an interest in international sales may
> > be a large faction of the overall IETF membership, but I might be wrong.
>
> You seem to be of the opinion that IETF exists to provide market
> opportunities to US companies.  You also seem to be of the
> opinion that US companies are somehow "members" of IETF.
> Finally, you seem to believe that IETF's mission is to endorse
> the Clinton administraton's cryptography policy by
> developing standards which are consistent with that policy.
>
> None of these is consistent with IETF policy.
>
> IETF is international in scope and does not exist to favor US
> companies in any way, regardless of how they might be impeded by
> their government.
>
> IETF is not a membership organization, and does not recognize
> companies as members. IETF policy is that individuals, not
> representatives of organizations, are the technical
> contributors to its working groups.  [see RFC 1603, sect 1.0,
> next to last paragraph]
>
> IETF emphatically does not endorse the policies of
> governments that prohibit use of encryption, restrict the
> export of cryptographic  technology, or restrict key lengths,
> or mandate government recovery  of keys.  [see RFC 1984]
>

At the last IETF a presentation was given showing IETF meeting
attendance verses location. When meetings were held outside
of North America attendance was low. In San Jose, attendance
was high. Both lows and highs were compared against meetings
held in other North American cities. I suspect from that data,
my own meeting attendance, and cursory examination of
previous "IETF MAILING: REGISTERED ATTENDEES" mail
messages, American companies do compose a substantial
percentage of IETF participants.

The IETF may not endorse crypto policies such as the US
Government's but those policies do have an impact on the work
coming out of the IETF. For example, TLS includes 40 bit crypto.
The GSS-API SESAME mechanism proposal includes 40 bit crypto.
The IPsec group made the 56 bit DES-CBC ESP transform mandatory
to make a political statement to the United States government
and to encourage US companies to put pressure on the government
to relax export restrictions; however, a 40 bit ESP transform
draft was recently submitted. S/MIME, I remember reading in a
document from RSA's Web site, includes 40 bit crypto due to US
export restrictions and the desire to have an international
interoperabe base, though S/MIME is not an IETF standard.

I think the conclusion that US export policies influence
standards is fair.

> If you're trying to achieve such ends, you're in the wrong
> organization.
>

-dpg

Date: Wed, 7 May 1997 16:22:24 -0700
To: [email-masked]
From: "Paul E. Hoffman" <[email-masked]>
Subject: RE: Restarting the 40-bit debate
Sender: [email-masked]

Hello!!? Anybody home?!?!

Sorry for the sarcasm, but I thought I had made my request explict. Let me
try again.

We are discussing a protocol here. It is defined in a spec. The spec is
publicly available.

Is there something wrong with the spec? Does it force weak cryptography?

The reason the spec has a 40-bit component is that a competing protocol
that doesn't have a 40-bit component has had very little implementation in
the years that it has been out. There may be other reasons for this, but
what I've heard from US implementors has been that they couldn't implement
it without a weak cryptography component, and what I've heard from the one
international developer I talked to was that they weren't going to bother
with it unless it was clear that US companies would.

Thus, there is a desire for a second protocol that might get a bit more
implemenentation. If there was wide implementation of the existing protocol
this protocol would be worse than useless, it would be destructive.
However, the opposite is true. It's mid-1997, and less than 1% of Internet
email users have good security or authentication.

Let's all work together on that Bad Situation, shall we?

The politics behind the lack of implementation for the other spec do *not*
matter; the viability of the current spec *does*. If the current spec
requires weak cryptography, we don't want it. Period. If the current spec
handles the weak cryptography in a fashion that allows people who don't
want to touch weak cryptography to still work with the spec, then it is
good.

Keith, Lindsay, and yes, even Blake: get back on topic. There is work to be
done here. Arguing about what's best for US industry, why US laws are bad,
and so on, IS A WASTE OF OUR TIME HERE. Looking carefully at the spec and
making sure it does not mandate weak cryptography is part of the work at
hand.

(And, yes, there are still many other issues on the open issues list.)

--Paul E. Hoffman, Director
--Internet Mail Consortium

From: Keith Moore <[email-masked]>
To: Lindsay Mathieson <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: Restarting the 40-bit debate 
Date: Wed, 07 May 1997 19:11:17 -0400
Sender: [email-masked]

> The only problem I have with implementing PGP, is its chaotic (well
> non-existent) programmers API, and no windows implementation

I was thinking more of the PGP data format than of utilities that
call PGP.  Granted, PGP would be a lot more widely deployed by
now if it had a callable API.

Keith

From: Blake Ramsdell <[email-masked]>
To: "'Lindsay Mathieson'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Restarting the 40-bit debate
Date: Wed, 7 May 1997 15:54:32 -0700
Sender: [email-masked]

On Wednesday, May 07, 1997 3:34 PM, Lindsay Mathieson
[SMTP:[email-masked]] wrote:
> I'm afraid what does tend to tick me off, is the assumption that the
> interests of US companies are the same as everybody else's - "Whats good for
> America is good for the rest of the world ..."

The only thing that I'm doing is recommending that the IETF standard
support a 40-bit algorithm in addition to a strong cryptographic
algorithm.  Nobody said that it was good for anyone except for US
for-profit software companies that implement S/MIME in exportable
products.  The only reason for pushing the issue is that I believe that
a large enough group of people are interested in this feature to make it
important to implement, and I don't believe that it hurts anyone if
implemented and used properly, which seems like it would be a no-brainer
to put in the spec.

I'm certainly not trying to make some political statement about "America
is superior to all other countries" -- certainly in the international
cryptographic game we're not.

Blake

Date: Wed, 7 May 1997 22:34:17 GMT
CC: [email-masked]
From: Lindsay Mathieson <[email-masked]>
Subject: RE: Restarting the 40-bit debate
To: Blake Ramsdell <[email-masked]>
Sender: [email-masked]

>It seems that US companies with an interest in international sales 
>may
>be a large faction of the overall IETF membership, but I might be 
>wrong.

I suspect so. There are many companies & independant developers from all over
the world here as well.

I'm afraid what does tend to tick me off, is the assumption that the
interests of US companies are the same as everybody else's - "Whats good for
America is good for the rest of the world ..."
--
Lindsay Mathieson
Black Paw Communications
	http://www.blackpaw.com/

Date: Wed, 7 May 1997 22:34:23 GMT
CC: [email-masked]
From: Lindsay Mathieson <[email-masked]>
Subject: Re: Restarting the 40-bit debate
To: Keith Moore <[email-masked]>
Sender: [email-masked]

>PGP has a reputation which
>gives it credibility in certain circles and undermines its 
>credibility in others.

The only problem I have with implementing PGP, is its chaotic (well
non-existent) programmers API, and no windows implementation

--
Lindsay Mathieson
Black Paw Communications
	http://www.blackpaw.com/

From: Keith Moore <[email-masked]>
To: Blake Ramsdell <[email-masked]>
cc: "'Keith Moore'" <[email-masked]>, "'Paul E. Hoffman'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Restarting the 40-bit debate 
Date: Wed, 07 May 1997 17:40:16 -0400
Sender: [email-masked]

> I think the point is that within the domain of US commercial for-profit
> software companies, strong-encryption-only specs are only going to
> appeal to those companies that don't consider their international sales
> to be important.
> 
> In my opinion, these companies are missing out on a large market that
> wants products.  [...]
> 
> It seems that US companies with an interest in international sales may
> be a large faction of the overall IETF membership, but I might be wrong.

You seem to be of the opinion that IETF exists to provide market
opportunities to US companies.  You also seem to be of the opinion
that US companies are somehow "members" of IETF.  Finally, you seem
to believe that IETF's mission is to endorse the Clinton administraton's
cryptography policy by developing standards which are consistent with
that policy.

None of these is consistent with IETF policy.

IETF is international in scope and does not exist to favor US 
companies in any way, regardless of how they might be impeded
by their government.

IETF is not a membership organization, and does not recognize 
companies as members. IETF policy is that individuals, not 
representatives of organizations, are the technical contributors
to its working groups.  [see RFC 1603, sect 1.0, next to last paragraph]

IETF emphatically does not endorse the policies of governments that
prohibit use of encryption, restrict the export of cryptographic 
technology, or restrict key lengths, or mandate government recovery 
of keys.  [see RFC 1984]

If you're trying to acheive such ends, you're in the wrong organization.

Keith

From: Keith Moore <[email-masked]>
To: Blake Ramsdell <[email-masked]>
cc: "'Keith Moore'" <[email-masked]>, "'Paul E. Hoffman'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Restarting the 40-bit debate 
Date: Wed, 07 May 1997 17:01:42 -0400
Sender: [email-masked]

> In these discussions I always end up at the same point.  Why is there no
> differentiation between a spec that allows the OPTION of using a weak
> algorithm, versus a REQUIREMENT of using a weak algorithm?  

Optional weak algorithms are fine, as long as there are mandantory
algorithms of sufficient strength, and as long as the optional 
algorithms are not endorsed as part of the standard.

Keith

From: Blake Ramsdell <[email-masked]>
To: "'Keith Moore'" <[email-masked]>, "'Paul E. Hoffman'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Restarting the 40-bit debate 
Date: Wed, 7 May 1997 13:40:32 -0700
Sender: [email-masked]

On Wednesday, May 07, 1997 9:44 AM, Keith Moore [SMTP:[email-masked]]
wrote:
> > As much as we may hate it, the US Government's refusal to let US
> > developers ship mail software with stronger security has pretty much
> > prevented all developers, inside the US and outside, from
> > implementing strong-encryption-only specs like PGP/MIME. 
> 
> I don't believe this.  First, there are many factors involved besides
> US export rules -- including the existance of patents and the
> licensing practices of certain firms.  PGP has a reputation which
> gives it credibility in certain circles and undermines its credibility
> in others.  Second, people are shipping strong encryption products
> both inside and outside the United States.

I think the point is that within the domain of US commercial for-profit
software companies, strong-encryption-only specs are only going to
appeal to those companies that don't consider their international sales
to be important.

In my opinion, these companies are missing out on a large market that
wants products.  We have a large customer base that is non-US,
non-Canada and I certainly don't consider ourselves to be the largest
company out there (which means that the Apples, IBMs and Microsofts of
the world are much more interested in this market than I am).

It seems that US companies with an interest in international sales may
be a large faction of the overall IETF membership, but I might be wrong.

> > I think it behooves us to come out with a spec that can be widely
> > implemented but does not force weak encryption.
> 
> People can define and use weak encryption algorithms if they want to.
> However, I sincerely doubt that something as weak as 40 bits can be
> considered of sufficient quality for the Internet standards track.

In these discussions I always end up at the same point.  Why is there no
differentiation between a spec that allows the OPTION of using a weak
algorithm, versus a REQUIREMENT of using a weak algorithm?  The argument
was presented here before that in the event that something is specified
as OPTIONAL, in practice it is always implemented, and thus everyone
will be using the weak algorithm.  I don't understand how people could
make money with such a product, since competitive products that didn't
take the "easy way" would stomp them because of the shortcoming.

Blake

From: Keith Moore <[email-masked]>
To: "Paul E. Hoffman" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Restarting the 40-bit debate 
Date: Wed, 07 May 1997 12:43:48 -0400
Sender: [email-masked]

> As much as we may hate it, the US Government's refusal to let US
> developers ship mail software with stronger security has pretty much
> prevented all developers, inside the US and outside, from
> implementing strong-encryption-only specs like PGP/MIME. 

I don't believe this.  First, there are many factors involved besides
US export rules -- including the existance of patents and the
licensing practices of certain firms.  PGP has a reputation which
gives it credibility in certain circles and undermines its credibility
in others.  Second, people are shipping strong encryption products
both inside and outside the United States.

> I think it behooves us to come out with a spec that can be widely
> implemented but does not force weak encryption.

People can define and use weak encryption algorithms if they want to.
However, I sincerely doubt that something as weak as 40 bits can be
considered of sufficient quality for the Internet standards track.

Keith

Date: Tue, 6 May 1997 17:05:35 -0700
To: [email-masked]
From: "Paul E. Hoffman" <[email-masked]>
Subject: Restarting the 40-bit debate
Sender: [email-masked]

One change we made in the -01 version of the drafts was to remove RC2 from
the main part of the draft, and to replace it with an "algorithm" called
"FOO/40". The purpose of this is give the list a round of not discussing
RC2, but fully discussing the use of a 40-bit weak algorithm.

Please read all of Section 2.6 and its subsections carefully. It is the
belief of the author team that there is nothing in this section that
requires sending using weak encryption, and gives you a precise guideline
for determining which encryption method to use in order to not send with
weak encryption.

I believe that naming and allowing a 40-bit algorithm in the spec will
cause many more developers to implement the spec; this is a Good Thing. As
much as we may hate it, the US Government's refusal to let US developers
ship mail software with stronger security has pretty much prevented all
developers, inside the US and outside, from implementing
strong-encryption-only specs like PGP/MIME. I think it behooves us to come
out with a spec that can be widely implemented but does not force weak
encryption.

--Paul E. Hoffman, Director
--Internet Mail Consortium

Date: Tue, 6 May 1997 16:46:13 -0700
To: [email-masked]
From: "Paul E. Hoffman" <[email-masked]>
Subject: New versions of the drafts available
Sender: [email-masked]

I've sent off the -01 versions of the two S/MIME drafts to the Internet
Drafts editor. To help avoid the wait for them to be posted on the official
directories, I've also updated the IMC copies at:
<http://www.imc.org/draft-dusse-smime-msg>
<http://www.imc.org/draft-dusse-smime-cert>

Each draft has a list of changes from the earlier version in an appendix
near the end of the draft. Please read them over and feel free to comment.

--Paul E. Hoffman, Director
--Internet Mail Consortium

From: Blake Ramsdell <[email-masked]>
To: Blake Ramsdell <[email-masked]>, "'Paul E. Hoffman'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Re[2]: IETF S/MIME and Algorithm Independence
Date: Fri, 2 May 1997 16:58:17 -0700
Sender: [email-masked]

On Friday, May 02, 1997 2:19 PM, Blake Ramsdell  wrote:
> I think that Russ' (and Bill's original) point was that the PKCS #7
> architecture has some things built into it that make it hard to use key
> management other than RSA.

Whoops.  I mean that "it makes it hard to use key management other than
X.509".  Sorry about that.

Blake

Date: Fri, 02 May 97 13:35:58 
From: "Housley, Russ" <[email-masked]>
To: [email-masked], "Paul E. Hoffman" <[email-masked]>
Subject: Re: IETF S/MIME and Algorithm Independence
Sender: [email-masked]

Paul:

>>Paul, the current structure mandates the use of RSA key management. The 
>>standrd
>>should not prohibit the use of other techniques such a Diffie-Hellman.  It is 
>>possible to have RSA as the "must implement" key management algorithm, but 
>>the
>>standardized structure should not prohibit the use of other techniques.
>
>And it doesn't. In fact, with the SMIMECapabilities, it makes it easy for 
>an agent that is using some other kind of key management to announce that 
>to the world on every signed and/or encrypted message it sends out. This 
>is described in the beginning of Section 2.5.2 of the drafts.

The PKCS#7 structure that supports S/MIME does not permit any key 
management algorithm to work.  For example, there is no place to carry the 
originator certificate that contains an Diffie-Hellman key.

Russ

From: Blake Ramsdell <[email-masked]>
To: "'Paul E. Hoffman'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Re[2]: IETF S/MIME and Algorithm Independence
Date: Fri, 2 May 1997 14:19:26 -0700
Sender: [email-masked]

On Friday, May 02, 1997 9:09 AM, Paul E. Hoffman [SMTP:[email-masked]]
wrote:
> >Paul, the current structure mandates the use of RSA key management. The
> >standrd
> >should not prohibit the use of other techniques such a Diffie-Hellman.  It
> >is
> >possible to have RSA as the "must implement" key management algorithm, but
> >the
> >standardized structure should not prohibit the use of other techniques.
> 
> And it doesn't. In fact, with the SMIMECapabilities, it makes it easy for
> an agent that is using some other kind of key management to announce that
> to the world on every signed and/or encrypted message it sends out. This is
> described in the beginning of Section 2.5.2 of the drafts.

I think that Russ' (and Bill's original) point was that the PKCS #7
architecture has some things built into it that make it hard to use key
management other than RSA.  For instance to identify the certificate
used to encrypt the session key for a recipient, an
"IssuerAndSerialNumber" is used which is the combination of the issuer
field and the serialNumber field from an X.509 certificate.  Likewise,
this same identifier is used for identifying a certificate that should
be used for signature verification.  This identifier is not
suitable/applicable for non-X.509 environments.  Also the certificate
shuttling mechanism is based on an ExtendedCertificateOrCertificate
which is an X.509 certificate, or a (deprecated) PKCS #6
ExtendedCertificate -- not really easy to put in something that isn't
X.509.

My understanding is that PKCS #7 is being worked on to address some of
these things.  SMIMECapabilites is helpful for supporting different
public-key models, but I think there's some more work that needs to be
done in order to have full support.

Blake

Date: Fri, 2 May 1997 09:08:40 -0700
To: [email-masked]
From: "Paul E. Hoffman" <[email-masked]>
Subject: Re[2]: IETF S/MIME and Algorithm Independence
Sender: [email-masked]

>>However, there was a mandate that we *not* do that on this work, that we
>>specify a minimum interoperability standard. That is, we don't want MOSS II.
>
>I disagree.  We want an algorithm independent protocol, but we want to pick a
>"must implement" algorithm that ensures interoperability.

Ah, I think I misunderstood the meaning of "algorithm independent
protocol". I my mind, "algorithm independent" means "all algorithms are
treated equally", which is what I spoke against. The current (and future)
drafts allow all algorithms, but mandate "must implement" for some of them.
To me, that's not "algorithm independent" but "multiple algorithm friendly".

I think we are in agreement here about what the spec does, just not the
terminolgy.

>Paul, the current structure mandates the use of RSA key management. The
>standrd
>should not prohibit the use of other techniques such a Diffie-Hellman.  It is
>possible to have RSA as the "must implement" key management algorithm, but
>the
>standardized structure should not prohibit the use of other techniques.

And it doesn't. In fact, with the SMIMECapabilities, it makes it easy for
an agent that is using some other kind of key management to announce that
to the world on every signed and/or encrypted message it sends out. This is
described in the beginning of Section 2.5.2 of the drafts.

--Paul E. Hoffman, Director
--Internet Mail Consortium

Date: Fri, 02 May 97 06:47:10 
From: "Housley, Russ" <[email-masked]>
To: [email-masked], "Paul E. Hoffman" <[email-masked]>
Subject: Re[2]: IETF S/MIME and Algorithm Independence
Sender: [email-masked]

>>I'd like to make an observation on the current IETF S/MIME draft that I 
>>think may need to be addressed.  I believe it is the IETF's goal to achieve 
>>algorithm-independent drafts wherever possible.
>
>However, there was a mandate that we *not* do that on this work, that we 
>specify a minimum interoperability standard. That is, we don't want MOSS II.

I disagree.  We want an algorithm independent protocol, but we want to pick a 
"must implement" algorithm that ensures interoperability.

>>While
>>PKCS #7 is an excellent standard for RSA messages, it is not currently 
>>designed to handle other types of cryptography.
>
>Well, we can all imagine why it was designed the way that it is. I'd be 
>interested in hearing about which other types of cryptography are prevented 
>by PKCS #7. With the SMIMECapabilities attributes, we're allowing 
>implementations to change anything, including the type of cryptography 
>used. This was specifically to allow the kinds of changes you want, so if 
>some are prevented by PKCS  #7, we should deal with that soon.

Paul, the current structure mandates the use of RSA key management. The standrd 
should not prohibit the use of other techniques such a Diffie-Hellman.  It is 
possible to have RSA as the "must implement" key management algorithm, but the 
standardized structure should not prohibit the use of other techniques.

Russ

Date: Thu, 1 May 1997 12:33:29 -0700
To: [email-masked]
From: "Paul E. Hoffman" <[email-masked]>
Subject: Re: IETF S/MIME and Algorithm Independence
Sender: [email-masked]

At 9:47 AM -0700 5/1/97, Bill Anderson wrote:
>I'd like to make an observation on the current IETF S/MIME draft that I
>think may need to be addressed.  I believe it is the IETF's goal to achieve
>algorithm-independent drafts wherever possible.

However, there was a mandate that we *not* do that on this work, that we
specify a minimum interoperability standard. That is, we don't want MOSS II.

>While
>PKCS #7 is an excellent standard for RSA messages, it is not currently
>designed to handle other types of cryptography.

Well, we can all imagine why it was designed the way that it is. I'd be
interested in hearing about which other types of cryptography are prevented
byt PKCS #7. With the SMIMECapabilities attributes, we're allowing
implementations to change anything, including the type of cryptography
used. This was specifically to allow the kinds of changes you want, so if
some are prevented by PKCS  #7, we should deal with that soon.

--Paul E. Hoffman, Director
--Internet Mail Consortium

Date: Thu, 1 May 1997 12:47:18 -0400
To: [email-masked]
From: Bill Anderson <[email-masked]>
Subject: IETF S/MIME and Algorithm Independence
Sender: [email-masked]

I'd like to make an observation on the current IETF S/MIME draft that I
think may need to be addressed.  I believe it is the IETF's goal to achieve
algorithm-independent drafts wherever possible.  This is certainly possible
for S/MIME, and I would suggest that it is also desirable.  

There is an opportunity to define the S/MIME specification to allow a
variety of public key algorithms.  For example, the NIST Digital Signature
Standard (DSS), the Elliptic Curve variant of DSS called ECDSA, and other
digital signaure algorithms could be used for 
signed messages.  Similarly, symmetric key wrapping could also be performed
by alternate public key algorithms.

I see a problem with this being achieved by the draft as it is written
because it appears to mandate the use of PKCS #7 message formats.  While
PKCS #7 is an excellent standard for RSA messages, it is not currently
designed to handle other types of cryptography.

To summarize:  The IETF S/MIME draft may be attempting to achieve algorithm
independence, but this attempt is defeated by the requirement for the
current PKCS #7 message format.

RSA has announced that it will be developing version 2.0 of the standard
over the next year.  The new standard is intended to be algorithm
independent, so this may solve one problem.  However, I think we need to be
aware that at present the PKCS #7 message format can not address all of the
requirements for an algorithm independent S/MIME standard.

Bill Anderson