Subject: Request for Moritorium: The RC2 debate
From: "Paul E. Hoffman" <[email-masked]>
To: [email-masked]
Date: Sat, 26 Apr 1997 10:09:23 -0700

Thank you all for participating in this discussion, and it has indeed
helped the document authors. (No smiley here: I mean it.) It has helped us
see where we need to clean up the spec, making it both more secure and
(hopefully) easier to understand. That's good, and that's what this kind of
work is all about. The author group is actively working on the next
revision of the drafts, and you should hopefully see them in a bit more
than a week.

The RC2 debate can temporarily be tabled with what I believe is the
following consensus:
the final draft will not have MUST or SHOULD text referring to RC2 if RSA
intends to treat RC2 as a trade secret. The next version of the drafts will
reflect this consensus.

I met with the folks at RSA yesterday. RSA still treats RC2 as a trade
secret, they are considering many options, they understand the July 1
deadline set by Jeff Schiller, they want a resolution well before that, and
they don't want the RC2 debate delaying the entire process.

On that note, I'd like to point out that there are a host of other open
issues listed in the drafts, and that some of you might have come up with
others. Please feel free to start new threads with any suggestions for
resolution on the open topics, or to bring up others. And, again, I request
that you read the drafts before posting to the list. The author group will
do its best to get the next round out soon.

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

Date: Sat, 26 Apr 1997 09:11:44 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: RE: The RC2 debate
To: Blake Ramsdell <[email-masked]>
Cc: "'Ned Freed'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Sender: [email-masked]

> Patented algorithms such as the RSA public-key algorithm, CAST or IDEA
> are a different issue, correct?  I understand that all of these
> particular algorithms have provisions for non-commercial use.  If they
> didn't, would there be a problem with putting them in the spec?

I'm afraid your understanding of the rules is somewhat out of date. This is
indeed the way it used to be, but it isn't any longer.

The current rules seem quite clear to me -- pure intellectual property issues
are something the IETF doesn't factor into their protocol design decisions. If
they are known they have to be documented, and an attempt has to be made to
obtain reasonable licensing terms (whatever that means), but that's it. As
such, there is no problem requiring a patented algorithm in a protocol, even if
the patent isn't easily licensable or has no provisions for non-commercial use.
The only way to keep such an algorithm out of the standard is to use the
interoperability requirements to say it cannot advance to draft because of a
lack of interoperable implementations, but all this means is that two different
parties have to be able to get a license, not that anyone has to be able to.
(And in this era of routine patent portfolio swaps among the big boys this
requirement is totally meaningless in practice.)

So there is no problem using RSA, Diffie-Hellman, LZW, or designing protocols
that negotiate compression along with encryption (this idea is patented,
believe it or not), or for that matter the 40-bit variant of DES that IBM
apparently has patented. (I'm still looking for a reference to this last, BTW,
but cannot find one that includes a useful description of the technique, let
alone a description of what the patent actually covers.)

The issue with RC2 isn't that it is covered by a trade secret and that trade
secrets never expire (this is one of Keith's pet peeves, but there's nothing in
the rules that forbids it that I know of), it is that trade secrets imply
confidentiality restrictions and such restrictions are forbidden regardless of
their origin. If a variant of trade secret existed that didn't require
confidentiality it would be perfectly acceptable under current IETF rules, even
if its IP claim never expired. (Of course such a variant cannot possibly exist
as the very foundation of trade secrecy lies in its confidentiality.)

Keith's point here is that he believes the IETF's rule of having to keep IP
issues out of the decision process means that RC2's trade secret status cannot
be used as a basis of rejecting the protocol. My counter is that the trade
secret status is irrelevant, it is the confidentiality restrictions implied by
this status that are unacceptable, and I find no language anywhere that allows
for an exception to the rules against confidentiality restrictions because the
confidentiality restriction arises as a result of a trade secret. 

BTW, I happen to disagree with the way the IETF chooses to treat patents now
and I argued against it at some length when the rule change was made, but the
consensus went the other way. This means, BTW, that should this WG decide to
replace RC2 with, say, the patented 40-bit IBM DES variant you would have to
license this new patent to implement S/MIME, and it would be just too bad if
IBM didn't have reasonable licensing terms available for it. See why I don't
like the present policy all that much?

				Ned

From: Blake Ramsdell <[email-masked]>
To: "'Ned Freed'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: The RC2 debate
Date: Fri, 25 Apr 1997 22:10:04 -0700
Sender: [email-masked]

OK, Blake the Chimp Boy has finally caught up with the class.  Clean
slate.

If S/MIME becomes standards track, then RC2 cannot even be mentioned as
a possible algorithm for use with the protocol.  This is because of its
trade secret status, as opposed to just being patented.

Patented algorithms such as the RSA public-key algorithm, CAST or IDEA
are a different issue, correct?  I understand that all of these
particular algorithms have provisions for non-commercial use.  If they
didn't, would there be a problem with putting them in the spec?

Blake

Date: Fri, 25 Apr 1997 18:44:03 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: The RC2 debate
To: Keith Moore <[email-masked]>
Cc: Blake Ramsdell <[email-masked]>, "'Ned Freed'" <[email-masked]>, "'Keith Moore'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Sender: [email-masked]

> > The only reason I stepped into this discussion was to clarify whether or
> > not the OPTIONAL use of RC2 is a violation of IETF guidelines, and as
> > far as I can tell it isn't.

> At least for the case of MIME content-type names, we allow assignment
> of names for proprietary content-types.  This was simply pragmatic:
> there were (unfortunately!) too many proprietary content-types that
> people wanted to use in MIME, (and were going to be used no matter what
> the IETF said) and we're better off having them clearly labeled.

I don't think this comparison is appropriate or useful. A much better
comparison would be to the members of the base set of content types defined in
the MIME specification. And in this case, as part of a standards-track
document, I have had to fight very hard to retain the set that's there now. (At
one point it even looked like there would be no primitive types in there other
than text/plain.)

In particular, it has been a major struggle to retain application/postscript,
even though this is an entirely optional part of the specification, the
specifications for PostScript are readily available and have no associated
confidentiality restrictions of any kind, there are lots of interoperable
implementations, a reasonably complete and comprehensive security analysis was
done early one, and so on. It also looks fairly likely that I'll be asked to
remove multipart/parallel from the base MIME specification and instead move it
to an informational document, simply because there don't seem to be a
sufficient number of agents that generate it on a regular basis to demonstrate
interoperability.

> I imagine that the working group will want to use some kind of
> algorithm identifier to specify what kind of encryption is being used.
> If so, the working group could decide the rules governing assignment
> of algorithm identifiers, and (for example) whether the algorithm had
> to have a published and openly available specification.  My guess
> is that a set of workable rules would end up being much like those
> for MIME types.

I agree but I don't think this is the point. The point is what ends up in the
base standards-track document defining S/MIME. I have no problem whatsoever
with a separate informational document that begins with a big disclaimer saying
the IETF hasn't blessed this in any way and then defines RC2 to some extent and
then says that its OID should you care to use it is such-and-such.

				Ned

Date: Fri, 25 Apr 1997 18:09:02 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: RE: The RC2 debate
To: Blake Ramsdell <[email-masked]>
Cc: "'Ned Freed'" <[email-masked]>, "'Keith Moore'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Sender: [email-masked]

> > Yes. My position is that RC2 cannot even be an optional part of the
> > specification unless it is released from trade secret restrictions. As a
> > trade
> > secret the most it can be is an informational part of the specification, and
> > preferably in a separate, informational document.

> I don't see the difference between my saying that the algorithm "can be
> used, but not as a MUST" and you saying that it can be "an informational
> part of the specification".  Both seem to refer to optional algorithms
> that can be used with the protocol.

I beg to differ. An optional part of a formal protocol specification is still
part of the specification. As such, it carries with it the IETF imprimateur and
all it implies -- it must undergo design and security analysis, it must meet
interoperability requirements, and so on. And perhaps more to the point,
anything described as a formal part of the protocol will be seen as something
implementations must provide; the labelling of mandatory versus optional tends
to be overlooked for the most part.

An informational document or appendix, on the other hand, is lightyears away
from this. An informational document is simply something someone decided to
publish. It is nothing more than that. It can be entirely cogent and relevant
or it can be the documented ravings of a lunatic. (And I'm afraid there are
RFCs that come very close to falling in the latter category.) It can be
extremely useful or an April Fool's prank. Other than the RFC editor and an
occasional IESG disclaimer, the IETF doesn't assess, bless, or condemn
informational documents in any way, shape, or form.

This is why the standards track designation is so important and why there's
an essential and fundamental difference between informational documents and
optional protocol elements in standards-track specifications.

> As far as a separate, informational document, Steve Dusse and the
> original S/MIME vendors had originally drafted the S/MIME spec using
> both a message specification (that talked about the MIME types and the
> use of multipart/signed), and an interoperability profile (describing
> the exact algorithms to be used in the specification).  The latest
> S/MIME draft fused these two documents together, and I'm not sure if
> that was the best idea.

The form the material takes it totally irrelevant. As a practical matter the
RFC editor will require separation of informational material from
standards-track material prior to publication, but this isn't something we
need to worry about at this time.

> I agree that algorithm specifics are best left
> to a separate document -- that way, in the event that the algorithms
> change for cryptographic or other reasons, the only document that needs
> to change is the one that specifies the algorithms.  The other documents
> (in this case, the overall MIME message format and the S/MIME
> certificate handling) will be unchanged.

We've been down this path many times before and dealt with this particular
problem in various different ways in different protocols. The bottom line is
that there's no good answer -- if you separate the material people will have
trouble putting the pieces together and if you don't people will have trouble
taking them apart. Experience has shown you cannot win on this one.

But be this as it may, it still simply isn't at all relevant to the issues at
hand.

> > P.S. I am also somewhat offended by your dismissive term "cranky" here.
> > There are sound technical and procedural reasons for the position I've taken here.

> Yes, you've voiced them, and you've whipped yourself into a frenzy (the
> "vociferous objection" paragraph from your last message.  I have trouble
> spelling it).  The point that I was making by trivializing your position
> as "being cranky" is to lighten the mood.  I'm sorry if it offended you,
> but I think that you got much too fired up about this.

You just can't seem to get away from being dismissive and condescending, can
you? Anyway, as far as "whipped into a frenzy" goes, I am not in anything even
remotely resembling a frenzy over this issue. (Some of you probably remember
some of the heated exchanges during the development of MIME; this present
matter pales into insignificance in comparison to those.)

All I have done here is make the extent and depth of my opposition to the
inclusion of RC2 with IP baggage attached in an IETF standard clear. And if you
think I'm joking, that this is simply a passing fancy of mine, or that I'm
making a mountain out of a molehill you are seriously mistaken. I meant every
word I said and I will do everything I said I would do should it become
necessary to do so.

> The only reason I stepped into this discussion was to clarify whether or
> not the OPTIONAL use of RC2 is a violation of IETF guidelines, and as
> far as I can tell it isn't.

And as far as I can tell it is. I will also point out that I sustantive
experience in this area, as I have in the past been forced to remove optional
protocol elements on the basis of IETF rules from documents I've edited, and
I'm pretty sure I will have to a lot more of these removals from documents I
edit in the future. (And no, I don't like having to do this, but I also
understand that there are very good reasons for us having the rules we do and I
have to follow them just like everyone else.)

> Please let me know if I have misunderstood
> your statement about its inclusion as an informational part of the
> specification as being equivalent to the OPTIONAL use of RC2.

My statement stands. My assessment is that RC2 cannot even be an optional part
of a standards track specification unless its IP status changes.

				Ned

From: Keith Moore <[email-masked]>
To: Blake Ramsdell <[email-masked]>
cc: "'Ned Freed'" <[email-masked]>, "'Keith Moore'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: The RC2 debate 
Date: Fri, 25 Apr 1997 17:07:34 -0400
Sender: [email-masked]

> The only reason I stepped into this discussion was to clarify whether or
> not the OPTIONAL use of RC2 is a violation of IETF guidelines, and as
> far as I can tell it isn't. 

At least for the case of MIME content-type names, we allow assignment 
of names for proprietary content-types.  This was simply pragmatic: 
there were (unfortunately!) too many proprietary content-types that 
people wanted to use in MIME, (and were going to be used no matter what
the IETF said) and we're better off having them clearly labeled.

I imagine that the working group will want to use some kind of 
algorithm identifier to specify what kind of encryption is being used.
If so, the working group could decide the rules governing assignment
of algorithm identifiers, and (for example) whether the algorithm had
to have a published and openly available specification.  My guess
is that a set of workable rules would end up being much like those 
for MIME types.

Keith

From: Blake Ramsdell <[email-masked]>
To: "'Ned Freed'" <[email-masked]>
Cc: "'Keith Moore'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: The RC2 debate
Date: Fri, 25 Apr 1997 13:58:30 -0700
Sender: [email-masked]

On Thursday, April 24, 1997 11:16 PM, Ned Freed
[SMTP:[email-masked]] wrote:
> Yes. My position is that RC2 cannot even be an optional part of the
> specification unless it is released from trade secret restrictions. As a
> trade
> secret the most it can be is an informational part of the specification, and
> preferably in a separate, informational document.

I don't see the difference between my saying that the algorithm "can be
used, but not as a MUST" and you saying that it can be "an informational
part of the specification".  Both seem to refer to optional algorithms
that can be used with the protocol.

As far as a separate, informational document, Steve Dusse and the
original S/MIME vendors had originally drafted the S/MIME spec using
both a message specification (that talked about the MIME types and the
use of multipart/signed), and an interoperability profile (describing
the exact algorithms to be used in the specification).  The latest
S/MIME draft fused these two documents together, and I'm not sure if
that was the best idea.  I agree that algorithm specifics are best left
to a separate document -- that way, in the event that the algorithms
change for cryptographic or other reasons, the only document that needs
to change is the one that specifies the algorithms.  The other documents
(in this case, the overall MIME message format and the S/MIME
certificate handling) will be unchanged.

> P.S. I am also somewhat offended by your dismissive term "cranky" here.
There
> are sound technical and procedural reasons for the position I've taken here.

Yes, you've voiced them, and you've whipped yourself into a frenzy (the
"vociferous objection" paragraph from your last message.  I have trouble
spelling it).  The point that I was making by trivializing your position
as "being cranky" is to lighten the mood.  I'm sorry if it offended you,
but I think that you got much too fired up about this.

The only reason I stepped into this discussion was to clarify whether or
not the OPTIONAL use of RC2 is a violation of IETF guidelines, and as
far as I can tell it isn't.  Please let me know if I have misunderstood
your statement about its inclusion as an informational part of the
specification as being equivalent to the OPTIONAL use of RC2.

Maybe the difference we are having is related to the physical separation
of the S/MIME message specification from the interoperability /
algorithm profile.

Blake

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: The RC2 debate 
Date: Fri, 25 Apr 1997 15:46:14 -0400
Sender: [email-masked]

>     Keith> RSA can complain "but that's *our* protocol", and IETF will
>     Keith> duly record that complaint, but that by itself won't stop
>     Keith> IETF from considering whether to use it.
>     ....................
>     Keith> Call it whatever you like, but that's what RFC 2026 says.
> 
> Excuse me, but who cares what RFC 2036 says? I thought we weren't
> discussing what RFC 2036 got to tell us?

Some people have been talking about in terms of use of RC2 being 
a violation of IETF process.  RFC 2026 defines that process, and
most of my contribution to this discussion has been an attempt to 
clarify that process.  People's beliefs about the process rules are 
very relevant to this discussion, because those beliefs color the
thinking about the solution space.

If a working group decides not to use RC2, that's fine with me.  But I 
hate to see a group making such a decision based on a misunderstanding 
of IETF process rules.  If the group understands the process rules,
and still makes the same decision, I'm a lot more comfortable.

> Everybody wants a standard that is free [to implement].

Only problem is, the intersection of "free to implement"  and
"compatible with s/mime" is the null set.

So do people here really want to define Yet Another Email Security 
Standard which can freely be implemented, even if it's incompatible
with anything else that's out there?

Keith

Date: Fri, 25 Apr 1997 14:31:01 -0400
From: Uri Blumenthal <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: [email-masked]
Subject: Re: The RC2 debate 
Reply-To: [email-masked]
Sender: [email-masked]

>>>>> "Keith" == Keith Moore <[email-masked]> writes:

    Keith> RSA can complain "but that's *our* protocol", and IETF will
    Keith> duly record that complaint, but that by itself won't stop
    Keith> IETF from considering whether to use it.
    ....................
    Keith> Call it whatever you like, but that's what RFC 2026 says.

Excuse me, but who cares what RFC 2036 says? I thought we weren't
discussing what RFC 2036 got to tell us?

    Keith> I strongly suspect that people are missing my point, but
    Keith> I'm tired of trying to explain it.  So I'll stop.  If you
    Keith> want further clarification, ask me in private mail.

Well, it is very possible that your point is missed/misunderstood.
However, let me explain what is the point that [mostly] everybody
else is making:  there is a proprietary algorithm that some would
want to "bless" as a standard, because they were [un]lucky enough
to purchase a license and implement it in their products.  Others
are afraid [and for a reason] that such an inclusion will make an
unencumbered implementation impossible due to a lawsuit threat
from the algorithm "owner". Those others thus violently
object against any attempt to sneak RC2 in.

It does NOT matter whether IESG allows to document an algorithm,
such as RC2. It does NOT matter whether a standard that includes
such an algorithm would or would not violate IETF rules (however
there is a strong opinion that it would).  

What DOES matter is that accepting such an algorithm can [and
most probably will] negatively affect the availability of the 
implementations.  Everybody wants a standard that is free [to 
implement].

The rest is irrelevant, IMHO.

Regards,                   [To reply, remove "NOSPAM!" from the 
Uri                         "Reply-To:" field]
-=-=-==-=-=-		[email-masked]
<Disclaimer>

Date: Thu, 24 Apr 1997 23:16:25 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: RE: The RC2 debate
To: Blake Ramsdell <[email-masked]>
Cc: "'Ned Freed'" <[email-masked]>, "'Keith Moore'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Sender: [email-masked]

> On Wednesday, April 23, 1997 11:07 AM, Ned Freed
> [SMTP:[email-masked]] wrote:
> > Keith, I don't mean to be unfriendly, but this is an absolute showstopper as
> > far as I'm concerned. So let me be blunt. I believe that progressing a
> > standard
> > with a RC2 reference in it is a formal violation of IETF rules as long the
> > status claimed by RSA doesn't change. And this is one rule I happen to
> > believe
> > must be enforced for the good of the IETF. I also believe I have backed this
> > up
> > with language from the applicable procedures in force today and that your
> > reading of the procedures is entirely specious.

> I don't understand -- the mere *mention* of RC2 in any IETF standard
> document will cause you to be all cranky?

Yes. My position is that RC2 cannot even be an optional part of the
specification unless it is released from trade secret restrictions. As a trade
secret the most it can be is an informational part of the specification, and
preferably in a separate, informational document.

I believe this is what RFC2026 requires. (I also understand Keith's argument on
this point -- I just happen to believe his analysis is totally incorrect.)

> I suppose what you mean is
> that if RC2 is a MUST then you will be all cranky.  I think this is an
> important distinction, so I'd like to get clarification on it.

Nope, that is not what I mean.

				Ned

P.S. I am also somewhat offended by your dismissive term "cranky" here. There
are sound technical and procedural reasons for the position I've taken here.

From: Blake Ramsdell <[email-masked]>
To: "'Ned Freed'" <[email-masked]>, "'Keith Moore'" <[email-masked]>
Cc: "'Keith Moore'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: The RC2 debate
Date: Thu, 24 Apr 1997 15:33:51 -0700
Sender: [email-masked]

On Wednesday, April 23, 1997 11:07 AM, Ned Freed
[SMTP:[email-masked]] wrote:
> Keith, I don't mean to be unfriendly, but this is an absolute showstopper as
> far as I'm concerned. So let me be blunt. I believe that progressing a
> standard
> with a RC2 reference in it is a formal violation of IETF rules as long the
> status claimed by RSA doesn't change. And this is one rule I happen to
> believe
> must be enforced for the good of the IETF. I also believe I have backed this
> up
> with language from the applicable procedures in force today and that your
> reading of the procedures is entirely specious.

I don't understand -- the mere *mention* of RC2 in any IETF standard
document will cause you to be all cranky?  I suppose what you mean is
that if RC2 is a MUST then you will be all cranky.  I think this is an
important distinction, so I'd like to get clarification on it.

Blake

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: The RC2 debate 
Date: Thu, 24 Apr 1997 16:32:32 -0400
Sender: [email-masked]

>     Keith> RSA can complain "but that's *our* protocol", and IETF will
>     Keith> duly record that complaint, but that by itself won't stop
>     Keith> IETF from considering whether to use it.
> 
> Childish. 

Call it whatever you like, but that's what RFC 2026 says.  

I strongly suspect that people are missing my point, but I'm tired of
trying to explain it.  So I'll stop.  If you want further
clarification, ask me in private mail.

Keith

Date: Wed, 23 Apr 1997 21:48:46 -0400
From: Uri Blumenthal <[email-masked]>
To: [email-masked]
Subject: Re: The RC2 debate 
Reply-To: [email-masked]
Sender: [email-masked]

>>>>> "Keith" == Keith Moore <[email-masked]> writes:

    Keith> RSA can complain "but that's *our* protocol", and IETF will
    Keith> duly record that complaint, but that by itself won't stop
    Keith> IETF from considering whether to use it.

Childish. 

It's not RSA complaining "it's our protocol" that people are 
concerned about - it's the threat of a lawsuit targeting 
anyone who's IMPLEMENTING this as you say "protocol" 
without RSADSI license. 

    Keith> To me the more interesting question is: assuming a working
    Keith> group received assurance from IESG that it would be allowed
    Keith> to publish an S/MIME spec that referenced someone else's
    Keith> RC2 specification, would it be able to reach consensus that
    Keith> this was the Right Thing to do?

Sure, as long as IESG assures the WG that it will pay for a lawyer to
defend an implementor of this "published spec" from a lawsuit by the
RSA. There is no reason to lock ourselves up in the proprietary ****.

Also, as I said, I follow Ned on this all the way. To IAB, if needed.

Regards,                   [To reply, remove "NOSPAM!" from the 
Uri                         "Reply-To:" field]
-=-=-==-=-=-		[email-masked]
<Disclaimer>

Date: Wed, 23 Apr 1997 21:40:34 -0400
From: Uri Blumenthal <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: The RC2 debate
Reply-To: [email-masked]
Sender: [email-masked]

Ned, count me in. I fully support your strong position.

Regards,                   [To reply, remove "NOSPAM!" from the 
Uri                         "Reply-To:" field]
-=-=-==-=-=-		[email-masked]
<Disclaimer>

From: Keith Moore <[email-masked]>
To: [email-masked] (David P. Kemp)
cc: [email-masked], [email-masked]
Subject: Re: The RC2 debate 
Date: Wed, 23 Apr 1997 17:38:23 -0400
Sender: [email-masked]

> What the IETF cares about is that proprietary algorithms not be
> REQUIRED, or even mentioned, in Standards Track specifications when
> suitable non-proprietary alternatives are available.  Freely-available
> symmetric algorithms exist in abundance, hence RC2 does not belong in the
> IETF-S/MIME Standard.

The specific language is at the end of section 7.1.2 in RFC 2026:

   The IESG generally should not favor a particular proprietary
   specification over technically equivalent and competing
   specification(s) by making any incorporated vendor specification
   "required" or "recommended".

Note that this constrains the IESG, not an IETF working group, and it
has to do with whether the IESG should recommend or require one
technology over another, not whether a technology can be placed on the
standards-track.  (Note also that it says "generally should not", not
"must not".)

IETF process rules do not prevent a working group from choosing a
proprietary technology, even when non-proprietary alternatives are
available.  Instead, we trust the working groups to make informed and
intelligent choices based on all appropriate criteria -- not just on
whether someone claims that a technology is their property.

> Regardless of the legal standing of the clean-room implementation,
> regardless of the existence of a published specification for RC2 (as an
> Information RFC, for example), there will always be the the threat of
> legal action unless RSA changes it's position.  The IETF's agnosticism
> on the validity of the claims is irrelevant - RSA's opinion, valid or
> not, is what counts.

This may indeed be what counts in the minds of some working group
participants, and such individual considerations may have an effect on
the group's consensus.

Keith

From: Keith Moore <[email-masked]>
To: Raph Levien <[email-masked]>
cc: Ned Freed <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked]
Subject: Re: The RC2 debate 
Date: Wed, 23 Apr 1997 15:05:41 -0400
Sender: [email-masked]

> As far as I can see, this absolutely decides the issue. For RC2 to be
> considered, RSA must agree that it is not confidential. Can there be any
> other interpretation? 

Yes.  The specification can come from somewhere other than RSA.

RSA can complain "but that's *our* protocol", and IETF will duly
record that complaint, but that by itself won't stop IETF from 
considering whether to use it.

To me the more interesting question is: assuming a working group 
received assurance from IESG that it would be allowed to publish 
an S/MIME spec that referenced someone else's RC2 specification, 
would it be able to reach consensus that this was the Right Thing to do?

Keith

Date: Wed, 23 Apr 1997 11:52:02 -0700 (PDT)
From: Raph Levien <[email-masked]>
To: Ned Freed <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], [email-masked]
Subject: Re: The RC2 debate
Sender: [email-masked]

I don't believe it's possible that RSA can both assert RC2 as a trade 
secret and have it considered in an IETF standard.

Section 10.2 is RFC 2026 is clear and unambiguous to me. However, another
section of RFC 2026 also seems relevant. Paragraph 5 of section 10.3 is
even clearer and more unambiguous: 

>    5. The contribuitor, the organization (if any) he represents and the
>       owners of any proprietary rights in the contribution, agree that
>       no information in the contribution is confidential and that the
>       ISOC and its affiliated organizations may freely disclose any
>       information in the contribution.

As far as I can see, this absolutely decides the issue. For RC2 to be
considered, RSA must agree that it is not confidential. Can there be any
other interpretation? 

Raph

From: Keith Moore <[email-masked]>
To: Ned Freed <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], [email-masked]
Subject: Re: The RC2 debate 
Date: Wed, 23 Apr 1997 14:44:17 -0400
Sender: [email-masked]

Ned, 

This is how I interpret RFC 2026, and this is where I will draw
the line on process grounds.  I've seen nothing in our recent
discussion that would cause me to change my interpretation.
Takiing no position on the validity of IPR claims is not tantamount 
to treating any trade secret claim as if it were valid.

The whole intent of the wording in 2026 is to take most IPR-related 
decisions out of the realm of process, and put them in the hands of 
the individuals in the community to be decided on a case-by-case basis.
As far as I can tell, this is the most effective and reasonable way of 
dealing with the IPR mess (disaster would be a better word) which has
ever been devised by a standards body...but only time will tell.

Of course, IF the working group is approved, and IF the working
group reaches consensus to use RC2, and IF the specification passes
the IESG, you're free to appeal that decision.  From a practical 
point-of-view, I have a hard time that the document will get that 
far without RSA's cooperation...not to mention yours.

Keith

Date: Wed, 23 Apr 1997 11:06:35 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: The RC2 debate
To: Keith Moore <[email-masked]>
Cc: Ned Freed <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

Keith, I think you're still missing the point I'm trying to make. You say:

> Section 10.2, as it applies to RC2, basically means that IETF can't
> reference RC2 in a standards-track protocol *if that reference* is
> subject to confidentiality restrictions.

The point is that RSA has claimed that any such reference *is* subject to
confidentiality restrictions. And you yourself have asserted that the IETF
cannot judge the merit of such a claim. As such, you have no choice but to
treat it as valid.

> So if an IETF WG wants to
> use RC2, it has to find a specification for that algorithm which is
> not subject to such restrictions.

RSA claims that this is flatly impossible to do.

> > Again I have to disagree. Publication is not the issue here, the
> > issue is RSA's claim to a confidentiality requirement that covers
> > RC2. As long as such a claim exists we cannot use RC2, period.

> I think we do disagree here.  But I for one won't object to use of RC2
> as long as the S/MIME specification can reference a published
> specification which is available to anyone.

Keith, I don't mean to be unfriendly, but this is an absolute showstopper as
far as I'm concerned. So let me be blunt. I believe that progressing a standard
with a RC2 reference in it is a formal violation of IETF rules as long the
status claimed by RSA doesn't change. And this is one rule I happen to believe
must be enforced for the good of the IETF. I also believe I have backed this up
with language from the applicable procedures in force today and that your
reading of the procedures is entirely specious.

As such, I will vociferously object to such a reference every step of the way
through the process, and if it the IESG sees fit to approve such a
specification in spite of my objections I will file a formal appeal with the
IAB, which I believe I will win.

				Ned

From: Keith Moore <[email-masked]>
To: Peter Whittaker <[email-masked]>
cc: "'Ned Freed'" <[email-masked]>, "'Keith Moore'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: The RC2 debate 
Date: Wed, 23 Apr 1997 14:03:46 -0400
Sender: [email-masked]

> The IETF does care:  they require that the owners of any licensed,
> patented, or otherwise restrictively controlled technologies release
> those technologies for use by the IETF.  

Nope.  IETF will *ask* them to agree to license it fairly, but *does
not* require them to do so.  A standards-track protocol can use
technology that is subject to IPR claims, even absent such a license,
if the concensus is to use that technology.

On the other hand, if the technology (for whatever reason) doesn't get
consensus of the community, it doesn't get used in a standards-track
protocol.

See RFC 2026 for the definitive statements.

Keith

From: Keith Moore <[email-masked]>
To: Ned Freed <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], [email-masked]
Subject: Re: The RC2 debate 
Date: Wed, 23 Apr 1997 13:58:32 -0400
Sender: [email-masked]

> > What IETF cares about is that the algorithm is a published standard
> > (either de facto or de jure), and that the technology is available
> > under reasonable and nondiscriminatory terms.
>  
> Keith, I'm afraid I must disagree with you on this. Again I cite the
> IETF rules published in RFC2026, specifically section 10.2:
> 
>   10.2  Confidentiality Obligations
> 
>      No contribution that is subject to any requirement of confidentiality
>      or any restriction on its dissemination may be considered in any part
>      of the Internet Standards Process, and there must be no assumption of
>      any confidentiality obligation with respect to any such contribution.

yes, but section 10.3.2 also says:

10.3.2. Standards Track Documents

   (A)  Where any patents, patent applications, or other proprietary
      rights are known, or claimed, with respect to any specification on
      the standards track, and brought to the attention of the IESG, the
      IESG shall not advance the specification without including in the
      document a note indicating the existence of such rights, or
      claimed rights.  Where implementations are required before
      advancement of a specification, only implementations that have, by
      statement of the implementors, taken adequate steps to comply with
      any such rights, or claimed rights, shall be considered for the
      purpose of showing the adequacy of the specification.
   (B)  The IESG disclaims any responsibility for identifying the
      existence of or for evaluating the applicability of any claimed
      copyrights, patents, patent applications, or other rights in the
      fulfilling of the its obligations under (A), and will take no
                                                   ^^^^^^^^^^^^^^^^
      position on the validity or scope of any such rights.
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   (C)  Where the IESG knows of rights, or claimed rights under (A), the
      IETF Executive Director shall attempt to obtain from the claimant
      of such rights, a written assurance that upon approval by the IESG
      of the relevant Internet standards track specification(s), any
      party will be able to obtain the right to implement, use and
      distribute the technology or works when implementing, using or
      distributing technology based upon the specific specification(s)
      under openly specified, reasonable, non-discriminatory terms.
      The Working Group proposing the use of the technology with respect
      to which the proprietary rights are claimed may assist the IETF
      Executive Director in this effort.  The results of this procedure
      shall not affect advancement of a specification along the
      standards track, except that the IESG may defer approval where a
      delay may facilitate the obtaining of such assurances.  The
      results will, however, be recorded by the IETF Executive Director,
      and made available.  The IESG may also direct that a summary of
      the results be included in any RFC published containing the
      specification.

So:

a. 10.3.2(B) says that even if RSA claims they have a trade secret, IETF
   will take no position on whether that claim is valid.

b. 10.3.2(A) says that if RSA informs the IESG that IETF's referencing 
   somebody else's RC2 spec is a violation of their intellectual 
   property rights, the IESG will duly note RSA's claim in any RFCs 
   that reference that RC2 spec.

c. 10.3.2(C) says that if RSA does claim rights, IETF will try to
   get them to agree to license the technology under fair terms,
   but whether such a license is granted DOES NOT prevent the
   advancement of the document along the standards track.

Note however that as a practical matter, if working group members
believe -- for whatever reason -- that a technology is too encumbered,
that algorithm might not gain consensus support for the group.

> A claim of a trade secret is at its core a claim of confidentiality, and
> RC2 is claimed to be a trade secret. As such, 10.2 applies and we cannot
> use RC2 in an Internet standard unless its status changes.

Nope.  The IETF stays out of the business of deciding whether the
claim has merit.

Again, individuals in the community can have their own opinions, and
if enough of those opinions are against using RC2, it will be
difficult for RC2 to get the consensus it needs to be part of an
Internet standards-track protocol.  But those individuals don't have
to agree on the reason for supporting or not supporting RC2.

Section 10.2, as it applies to RC2, basically means that IETF can't
reference RC2 in a standards-track protocol *if that reference* is
subject to confidentiality restrictions.  So if an IETF WG wants to
use RC2, it has to find a specification for that algorithm which is
not subject to such restrictions.

> > If RSA publishes the algorithm, fine; if the algorithm is published by
> > somebody else, fine.  But it does have to be published.  If this WG
> > can't find a RC2 specification to reference, it needs to use some
> > other symmetric encryption algorithm.   (And IMHO it shouldn't waste any
> > more time waiting for RSA to make up its mind...RSA has had plenty of time
> > to publish RC2 if it wants to do that.)
> 
> Again I have to disagree. Publication is not the issue here, the
> issue is RSA's claim to a confidentiality requirement that covers 
> RC2. As long as such a claim exists we cannot use RC2, period.

I think we do disagree here.  But I for one won't object to use of RC2
as long as the S/MIME specification can reference a published
specification which is available to anyone.

> > IETF rules are very clear: we don't take any position as to the validity
> > of anybody else's intellectual property claims.
> 
> Exactly, and this is the entire point. Since the IETF isn't in the 
> business of assessing the validity of IP claims it has no choice 
> but to treat the RSA claims as potentially valid.

"I don't think that means what you think it means"...  though I don't
think I can state things more clearly than section 10.3.2 of RFC 2026.

> Specifically, the ongoing efforts of RSA to keep the details of RC2
> (and to a lesser extent RC4) secret have had a chilling effort on
> analysis of these algorithms in the cryptographic community.  Simply
> put, I know of the existance of no cryptographic results for RC2
> (and precious few for RC4). Now, when it comes to cryptographic
> algorithms, it is almost axiomatic that trust only comes after
> careful scrutiny. And while Ron Rivest is a highly competent
> cryptographer with excellent credentials, he nevertheless could have
> made some mistake in the design of RC2. And if I put on my
> mathematician hat for a moment, I'm also uncomfortable with some of
> the design elements in RC2; the S-box seems a bit small given that
> it is initialized more or less at random.

Yes, these are indeed problems.  But it's up to the community to
decide whether an algorithm is suitable for a particular purpose.

Keith

Date: Wed, 23 Apr 1997 09:15:35 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: The RC2 debate
To: Keith Moore <[email-masked]>
Cc: Ned Freed <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> > And it is totally irrelevant anyway. The stated position of RSA here,
> > which has in fact been posted to this list by RSA representatives, is
> > that they believe this algorithm is still covered by trade secret rules.

> I for one don't really care whether RSA thinks that RC2 is a trade secret.
> (or for that matter, what RSA's reasoning is)
> Just because RSA has an opinion doesn't mean IETF is bound by it.

> What IETF cares about is that the algorithm is a published standard
> (either de facto or de jure), and that the technology is available
> under reasonable and nondiscriminatory terms.
 
Keith, I'm afraid I must disagree with you on this. Again I cite the
IETF rules published in RFC2026, specifically section 10.2:

  10.2  Confidentiality Obligations

     No contribution that is subject to any requirement of confidentiality
     or any restriction on its dissemination may be considered in any part
     of the Internet Standards Process, and there must be no assumption of
     any confidentiality obligation with respect to any such contribution.

A claim of a trade secret is at its core a claim of confidentiality, and
RC2 is claimed to be a trade secret. As such, 10.2 applies and we cannot
use RC2 in an Internet standard unless its status changes.

> If RSA publishes the algorithm, fine; if the algorithm is published by
> somebody else, fine.  But it does have to be published.  If this WG
> can't find a RC2 specification to reference, it needs to use some
> other symmetric encryption algorithm.   (And IMHO it shouldn't waste any
> more time waiting for RSA to make up its mind...RSA has had plenty of time
> to publish RC2 if it wants to do that.)

Again I have to disagree. Publication is not the issue here, the issue is RSA's
claim to a confidentiality requirement that covers RC2. As long as such a claim
exists we cannot use RC2, period.

> > This means that confidentiality restrictions may still apply, a zillion
> > postings to various newsgroups notwithstanding.  And this in turn means
> > that it is a nonstarter as far as the IETF is concerned. Again, the
> > IETF rules concerning this could not be any clearer.

> IETF rules are very clear: we don't take any position as to the validity
> of anybody else's intellectual property claims.

Exactly, and this is the entire point. Since the IETF isn't in the business of
assessing the validity of IP claims it has no choice but to treat the RSA
claims as potentially valid.

The underlying problem here seems to be that you think this rule means we can
ignore IP issues entirely. It doesn't say this at all. The validity rule is
there to keep us out of IP disputes and to keep IP issues out of our technical
decision-making process to the greatest extent possible. And when it comes to
patents this works quite well, since most patents carry with them no
confidentiality restrictions (NSA patents are an exception, BTW.) and by being
able to ignore patent status we get to pick the best technology to solve a
given problem.

But in the case of trade secrets confidentiality restrictions exist as well,
and the existance of such absolutely does cause interference in the technical
decision-making process. As this has been dealt with by saying that such
restrictions cannnot exist for standardized technology.

I'd like to expand on the last point a bit because it happens to provide a
sound technical basis for rejecting RC2 as well as the more obvious rule-based
one. Specifically, the ongoing efforts of RSA to keep the details of RC2 (and
to a lesser extent RC4) secret have had a chilling effort on analysis of these
algorithms in the cryptographic community. Simply put, I know of the existance
of no cryptographic results for RC2 (and precious few for RC4). Now, when it
comes to cryptographic algorithms, it is almost axiomatic that trust only comes
after careful scrutiny. And while Ron Rivest is a highly competent
cryptographer with excellent credentials, he nevertheless could have made some
mistake in the design of RC2. And if I put on my mathematician hat for a
moment, I'm also uncomfortable with some of the design elements in RC2; the
S-box seems a bit small given that it is initialized more or less at random.

Others have pointed out that there isn't exactly a shortage of unencumbered
symmetric key algorithms, algorithms that have been cryptanalyzed extensively
and have withstood the best efforts of the community for many years. It
will years before RC2 attains this status, assuming it ever does. As such,
there is also a sound technical reason for rejecting RC2 as the algorithm
for use in S/MIME.

				Ned

Date: Wed, 23 Apr 1997 09:45:19 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: The RC2 debate
Sender: [email-masked]

> From: Keith Moore <[email-masked]>
> 
> > And it is totally irrelevant anyway. The stated position of RSA here, 
> > which has in fact been posted to this list by RSA representatives, is 
> > that they believe this algorithm is still covered by trade secret rules. 
> 
> I for one don't really care whether RSA thinks that RC2 is a trade secret.
> (or for that matter, what RSA's reasoning is)
> Just because RSA has an opinion doesn't mean IETF is bound by it.
> 
> What IETF cares about is that the algorithm is a published standard
> (either de facto or de jure), and that the technology is available 
> under reasonable and nondiscriminatory terms.

What the IETF cares about is that proprietary algorithms not be
REQUIRED, or even mentioned, in Standards Track specifications when
suitable non-proprietary alternatives are available.  Freely-available
symmetric algorithms exist in abundance, hence RC2 does not belong in the
IETF-S/MIME Standard.

Implementors of IETF-S/MIME software are always free to also implement RC2,
using either licensed or unlicensed code, over and above the requirements
of the IETF specification.  Many of them probably will, for backward
interoperability.

Regardless of the legal standing of the clean-room implementation,
regardless of the existence of a published specification for RC2 (as an
Information RFC, for example), there will always be the the threat of
legal action unless RSA changes it's position.  The IETF's agnosticism
on the validity of the claims is irrelevant - RSA's opinion, valid or
not, is what counts.

Ned Freed's superlative analysis should be the last word on this issue.
How could anyone read it and not be convinced?

From: Peter Whittaker <[email-masked]>
To: "'Ned Freed'" <[email-masked]>, "'Keith Moore'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: The RC2 debate
Date: Wed, 23 Apr 1997 08:29:22 -0400
Sender: [email-masked]

>> And it is totally irrelevant anyway. The stated position of RSA here, 
>> which has in fact been posted to this list by RSA representatives, is 
>> that they believe this algorithm is still covered by trade secret rules. 
>
>I for one don't really care whether RSA thinks that RC2 is a trade secret.
>(or for that matter, what RSA's reasoning is)
>Just because RSA has an opinion doesn't mean IETF is bound by it.
>
>What IETF cares about is that the algorithm is a published standard
>(either de facto or de jure), and that the technology is available 
>under reasonable and nondiscriminatory terms.
> 
>If RSA publishes the algorithm, fine; if the algorithm is published by
>somebody else, fine.  But it does have to be published.  If this WG
>can't find a RC2 specification to reference, it needs to use some
>other symmetric encryption algorithm.   (And IMHO it shouldn't waste any
>more time waiting for RSA to make up its mind...RSA has had plenty of time
>to publish RC2 if it wants to do that.)

The IETF does care:  they require that the owners of any licensed,
patented, or otherwise restrictively controlled technologies release
those technologies for use by the IETF.  Having one party publish an
informational RFC that allows others to implement a technology owned by
another party would be wildly irreponsible (as the owner could sue the
IETF in all probability, along with the RFC author), and would not allow
the IETF or anyone else to use the technology, as it would still be
owned by the owner.

When licensed technologies are involved, the IETF requires that the
owners of the technology make it available, somehow.  Take a look at the
release in RFC 1319:  License to use MD2 is granted for non-commerical
Internet Privacy-Enhanced Mail.  On the other hand, MD4 (1320) and MD5
(1321) are placed in the public domain.

In this case, the IETF can only consider algorithms for which exist
appropriate informational RFCs documenting the algorithm and releasing
it for use within the IETF (or for broader use).

pww

From: Keith Moore <[email-masked]>
To: Ned Freed <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], [email-masked]
Subject: Re: The RC2 debate 
Date: Wed, 23 Apr 1997 03:15:35 -0400
Sender: [email-masked]

> And it is totally irrelevant anyway. The stated position of RSA here, 
> which has in fact been posted to this list by RSA representatives, is 
> that they believe this algorithm is still covered by trade secret rules. 

I for one don't really care whether RSA thinks that RC2 is a trade secret.
(or for that matter, what RSA's reasoning is)
Just because RSA has an opinion doesn't mean IETF is bound by it.

What IETF cares about is that the algorithm is a published standard
(either de facto or de jure), and that the technology is available 
under reasonable and nondiscriminatory terms.
 
If RSA publishes the algorithm, fine; if the algorithm is published by
somebody else, fine.  But it does have to be published.  If this WG
can't find a RC2 specification to reference, it needs to use some
other symmetric encryption algorithm.   (And IMHO it shouldn't waste any
more time waiting for RSA to make up its mind...RSA has had plenty of time
to publish RC2 if it wants to do that.)

> This means that confidentiality restrictions may still apply, a zillion 
> postings to various newsgroups notwithstanding.  And this in turn means 
> that it is a nonstarter as far as the IETF is concerned. Again, the 
> IETF rules concerning this could not be any clearer.

IETF rules are very clear: we don't take any position as to the validity
of anybody else's intellectual property claims.  

Keith

Date: Tue, 22 Apr 1997 22:23:21 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: The RC2 debate
To: Keith Moore <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> > 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]>.  This has also ended up on a
> > number of FTP sites, and I've seen it on at least one CDROM archive.
> > I assume that's enough to qualify it as "widely published".

> No, I don't think so.  Neither random FTP sites nor a CDROM archive give
> me any confidence that the specification will be widely available for a
> reasonable amount of time.

And it is totally irrelevant anyway. The stated position of RSA here, which has
in fact been posted to this list by RSA representatives, is that they believe
this algorithm is still covered by trade secret rules. This means that
confidentiality restrictions may still apply, a zillion postings to various
newsgroups notwithstanding.  And this in turn means that it is a nonstarter as
far as the IETF is concerned. Again, the IETF rules concerning this could not
be any clearer.

More specifically, my understanding of RSA's claim is that they believe all
published descriptions of RC2 have been arrived at by reverse engineering code
covered by a license that forbids such reverse engineering. The question of
whether the "chinese wall" or "clean room" approach that was used is sufficient
to invalidate RSA's claims is something that only a court case can decide --
until that happens and RSA is successfully challenged in court and the trade
secret status of RC2 is invalidated their position is what counts. Moreover,
since trade secret law varies somewhat from one jurisdiction to another, it is
even possible that a single successful challenge would be insufficient to
invalidate all their claims (and this supposed they would lose, which is far
from obvious to me).

Finally, I would not recommend that anyone get their hopes over such a
challenge ever actually happening. At present RSA clearly believes that
maintaining trade secret status is important. As such, if they were ever placed
in a position where they would be likely to lose their trade secret status
through a legal challenge they would probably simply agree to a license for
less than the challenge is going to cost the challenger. And putting on my
corporate officer hat for a moment, it is unlikely that a company, especially a
public one, would ever turn down such a deal. Companies, even private ones,
have a fiduciary responsibility to their stockholders. They do not have a
responsibility to engage in expensive legal actions to prove a point, even when
those actions are clearly for the good of the community.

				Ned

Date: Tue, 22 Apr 1997 20:56:49 -0700
To: [email-masked], [email-masked]
From: [email-masked] (Jeff Smith)
Subject: Re: The RC2 debate
Sender: [email-masked]

Although the analogy is not completely relevant, note
that LZW was published everywhere before Unisys
decided to extract royalties for any use of the algorithm.
Yes, a patent applied to LZW...

Also, clean rooms don't always yield the desired results.
For example, ask AMD whether Intel was satisfied.

>From my perspective the only truly clean solution
is for RSA to open up RC2.  Otherwise, there is risk, 
the algo remains proprietary, and it simply
should not be included in the specification.

-- jeff

At 10:25 AM 4/23/97, Peter Gutmann wrote:
>Since I've had several requests and questions about this (and I'll probably
>never hear the end of it otherwise), here's the RC2 clean-room stuff
including
>the spec.
> 
>Peter.
> 
>-- The original message, from a source in the Netherlands --
> 
>Newsgroups: sci.crypt
>From: [email-masked] (Anonymous)
>Subject: RC2 source code
>Date: 29 Jan 1996 06:38:04 +0100
>Organization: Hack-Tic International, Inc.
>Message-ID: <[email-masked]>
> 
>[Reverse-engineered RC2 code]
> 
>-- My spec for RRC.2, from New Zealand --
> 
>Newsgroups: sci.crypt
>From: [email-masked] (Peter Gutmann)
>Subject: Specification for Ron Rivests Cipher No.2
>Date: 11 Feb 1996 06:45:03 GMT
>Organization: University of Auckland
>Message-ID: <[email-masked]>
> 
>                           Ron Rivest's Cipher No.2
>                           ------------------------
> 
>Ron Rivest's Cipher No.2 (hereafter referred to as RRC.2, other people may
>refer to it by other names) is word oriented, operating on a block of 64 bits
>divided into four 16-bit words, with a key table of 64 words.  All data units
>are little-endian.  This functional description of the algorithm is based in
>the paper "The RC5 Encryption Algorithm" (RC5 is a trademark of RSADSI),
using
>the same general layout, terminology, and pseudocode style.
> 
> 
>Notation and RRC.2 Primitive Operations
> 
>RRC.2 uses the following primitive operations:
> 
>1. Two's-complement addition of words, denoted by "+".  The inverse
operation,
>   subtraction, is denoted by "-".
>2. Bitwise exclusive OR, denoted by "^".
>3. Bitwise AND, denoted by "&".
>4. Bitwise NOT, denoted by "~".
>5. A left-rotation of words; the rotation of word x left by y is denoted
>   x <<< y.  The inverse operation, right-rotation, is denoted x >>> y.
> 
>These operations are directly and efficiently supported by most processors.
> 
> 
>The RRC.2 Algorithm
> 
>RRC.2 consists of three components, a *key expansion* algorithm, an
>*encryption* algorithm, and a *decryption* algorithm.
> 
> 
>Key Expansion
> 
>The purpose of the key-expansion routine is to expand the user's key K to
fill
>the expanded key array S, so S resembles an array of random binary words
>determined by the user's secret key K.
> 
>Initialising the S-box
> 
>RRC.2 uses a single 256-byte S-box derived from the ciphertext contents of
>Beale Cipher No.1 XOR'd with a one-time pad.  The Beale Ciphers predate
modern
>cryptography by enough time that there should be no concerns about trapdoors
>hidden in the data.  They have been published widely, and the S-box can be
>easily recreated from the one-time pad values and the Beale Cipher data taken
>from a standard source.  To initialise the S-box:
> 
>  for i = 0 to 255 do
>    sBox[ i ] = ( beale[ i ] mod 256 ) ^ pad[ i ]
> 
>The contents of Beale Cipher No.1 and the necessary one-time pad are given as
>an appendix at the end of this document.  For efficiency, implementors may
wish
>to skip the Beale Cipher expansion and store the sBox table directly.
> 
>Expanding the Secret Key to 128 Bytes
> 
>The secret key is first expanded to fill 128 bytes (64 words).  The expansion
>consists of taking the sum of the first and last bytes in the user key,
looking
>up the sum (modulo 256) in the S-box, and appending the result to the key.
 The
>operation is repeated with the second byte and new last byte of the key until
>all 128 bytes have been generated.  Note that the following pseudocode treats
>the S array as an array of 128 bytes rather than 64 words.
> 
>  for j = 0 to length-1 do
>    S[ j ] = K[ j ]
>  for j = length to 127 do
>    s[ j ] = sBox[ ( S[ j-length ] + S[ j-1 ] ) mod 256 ];
> 
>At this point it is possible to perform a truncation of the effective key
>length to ease the creation of espionage-enabled software products.  However
>since the author cannot conceive why anyone would want to do this, it will
not
>be considered further.
> 
>The final phase of the key expansion involves replacing the first byte of S
>with the entry selected from the S-box:
> 
>  S[ 0 ] = sBox[ S[ 0 ] ]
> 
> 
>Encryption
> 
>The cipher has 16 full rounds, each divided into 4 subrounds.  Two of the
full
>rounds perform an additional transformation on the data.  Note that the
>following pseudocode treats the S array as an array of 64 words rather
than 128
>bytes.
> 
>  for i = 0 to 15 do
>    j = i * 4;
>    word0 = ( word0 + ( word1 & ~word3 ) + ( word2 & word3 ) + S[ j+0 ] )
<<< 1
>    word1 = ( word1 + ( word2 & ~word0 ) + ( word3 & word0 ) + S[ j+1 ] )
<<< 2
>    word2 = ( word2 + ( word3 & ~word1 ) + ( word0 & word1 ) + S[ j+2 ] )
<<< 3
>    word3 = ( word3 + ( word0 & ~word2 ) + ( word1 & word2 ) + S[ j+3 ] )
<<< 5
> 
>In addition the fifth and eleventh rounds add the contents of the S-box
indexed
>by one of the data words to another of the data words following the four
>subrounds as follows:
> 
>    word0 = word0 + S[ word3 & 63 ];
>    word1 = word1 + S[ word0 & 63 ];
>    word2 = word2 + S[ word1 & 63 ];
>    word3 = word3 + S[ word2 & 63 ];
> 
> 
>Decryption
> 
>The decryption operation is simply the inverse of the encryption operation.
>Note that the following pseudocode treats the S array as an array of 64 words
>rather than 128 bytes.
> 
>  for i = 15 downto 0 do
>    j = i * 4;
>    word3 = ( word3 >>> 5 ) - ( word0 & ~word2 ) - ( word1 & word2 ) - S[
j+3 ]
>    word2 = ( word2 >>> 3 ) - ( word3 & ~word1 ) - ( word0 & word1 ) - S[
j+2 ]
>    word1 = ( word1 >>> 2 ) - ( word2 & ~word0 ) - ( word3 & word0 ) - S[
j+1 ]
>    word0 = ( word0 >>> 1 ) - ( word1 & ~word3 ) - ( word2 & word3 ) - S[
j+0 ]
> 
>In addition the fifth and eleventh rounds subtract the contents of the S-box
>indexed by one of the data words from another one of the data words following
>the four subrounds as follows:
> 
>    word3 = word3 - S[ word2 & 63 ]
>    word2 = word2 - S[ word1 & 63 ]
>    word1 = word1 - S[ word0 & 63 ]
>    word0 = word0 - S[ word3 & 63 ]
> 
> 
>Test Vectors
> 
>The following test vectors may be used to test the correctness of an RRC.2
>implementation:
> 
>  Key:      0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>            0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
>  Plain:    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
>  Cipher:   0x1C, 0x19, 0x8A, 0x83, 0x8D, 0xF0, 0x28, 0xB7
> 
>  Key:      0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>            0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01
>  Plain:    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
>  Cipher:   0x21, 0x82, 0x9C, 0x78, 0xA9, 0xF9, 0xC0, 0x74
> 
>  Key:      0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>            0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
>  Plain:    0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
>  Cipher:   0x13, 0xDB, 0x35, 0x17, 0xD3, 0x21, 0x86, 0x9E
> 
>  Key:      0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
>            0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F
>  Plain:    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
>  Cipher:   0x50, 0xDC, 0x01, 0x62, 0xBD, 0x75, 0x7F, 0x31
> 
> 
>Appendix: Beale Cipher No.1, "The Locality of the Vault", and One-time Pad
for
>          Creating the S-Box
> 
>Beale Cipher No.1.
> 
>  71, 194,  38,1701,  89,  76,  11,  83,1629,  48,  94,  63, 132,  16,
111,  95,
>  84, 341, 975,  14,  40,  64,  27,  81, 139, 213,  63,  90,1120,   8,
15,   3,
> 126,2018,  40,  74, 758, 485, 604, 230, 436, 664, 582, 150, 251, 284,
308, 231,
> 124, 211, 486, 225, 401, 370,  11, 101, 305, 139, 189,  17,  33,  88,
208, 193,
> 145,   1,  94,  73, 416, 918, 263,  28, 500, 538, 356, 117, 136, 219,
27, 176,
> 130,  10, 460,  25, 485,  18, 436,  65,  84, 200, 283, 118, 320, 138,
36, 416,
> 280,  15,  71, 224, 961,  44,  16, 401,  39,  88,  61, 304,  12,  21,
24, 283,
> 134,  92,  63, 246, 486, 682,   7, 219, 184, 360, 780,  18,  64, 463,
474, 131,
> 160,  79,  73, 440,  95,  18,  64, 581,  34,  69, 128, 367, 460,  17,
81,  12,
> 103, 820,  62, 110,  97, 103, 862,  70,  60,1317, 471, 540, 208, 121,
890, 346,
>  36, 150,  59, 568, 614,  13, 120,  63, 219, 812,2160,1780,  99,  35,
18,  21,
> 136, 872,  15,  28, 170,  88,   4,  30,  44, 112,  18, 147, 436, 195,
320,  37,
> 122, 113,   6, 140,   8, 120, 305,  42,  58, 461,  44, 106, 301,  13,
408, 680,
>  93,  86, 116, 530,  82, 568,   9, 102,  38, 416,  89,  71, 216, 728,
965, 818,
>   2,  38, 121, 195,  14, 326, 148, 234,  18,  55, 131, 234, 361, 824,
5,  81,
> 623,  48, 961,  19,  26,  33,  10,1101, 365,  92,  88, 181, 275, 346,
201, 206
> 
>One-time Pad.
> 
> 158, 186, 223,  97,  64, 145, 190, 190, 117, 217, 163,  70, 206, 176,
183, 194,
> 146,  43, 248, 141,   3,  54,  72, 223, 233, 153,  91, 210,  36, 131,
244, 161,
> 105, 120, 113, 191, 113,  86,  19, 245, 213, 221,  43,  27, 242, 157,
73, 213,
> 193,  92, 166,  10,  23, 197, 112, 110, 193,  30, 156,  51, 125,  51,
158,  67,
> 197, 215,  59, 218, 110, 246, 181,   0, 135,  76, 164,  97,  47,  87,
234, 108,
> 144, 127,   6,   6, 222, 172,  80, 144,  22, 245, 207,  70, 227, 182,
146, 134,
> 119, 176,  73,  58, 135,  69,  23, 198,   0, 170,  32, 171, 176, 129,
91,  24,
> 126,  77, 248,   0, 118,  69,  57,  60, 190, 171, 217,  61, 136, 169,
196,  84,
> 168, 167, 163, 102, 223,  64, 174, 178, 166, 239, 242, 195, 249,  92,
59,  38,
> 241,  46, 236,  31,  59, 114,  23,  50, 119, 186,   7,  66, 212,  97,
222, 182,
> 230, 118, 122,  86, 105,  92, 179, 243, 255, 189, 223, 164, 194, 215,
98,  44,
>  17,  20,  53, 153, 137, 224, 176, 100, 208, 114,  36, 200, 145, 150,
215,  20,
>  87,  44, 252,  20, 235, 242, 163, 132,  63,  18,   5, 122,  74,  97,
34,  97,
> 142,  86, 146, 221, 179, 166, 161,  74,  69, 182,  88, 120, 128,  58,
76, 155,
>  15,  30,  77, 216, 165, 117, 107,  90, 169, 127, 143, 181, 208, 137,
200, 127,
> 170, 195,  26,  84, 255, 132, 150,  58, 103, 250, 120, 221, 237,  37,
8,  99
> 
> 
>Implementation
> 
>A non-US based programmer who has never seen any encryption code before will
>shortly be implementing RRC.2 based solely on this specification and not on
>knowledge of any other encryption algorithms.  Stand by.
> 
>-- The announcement of the clean-room version, from Germany --
> 
>Newsgroups: sci.crypt
>From: [email-masked] (Daniel Vogelheim)
>Subject: RRC.2 implementation available
>Date: 18 Feb 1996 01:06:08 GMT
>Organization: RWTH -Aachen / Rechnerbetrieb Informatik
>Message-ID: <[email-masked]>
> 
>Hi,
> 
>I have implemented the RRC.2 cipher and want to make it available to anybody
>interested. Since I am new to cryptography the code probably isn't of high
>quality by professional measures, though. (I plan to improve it as I learn.)
> 
>[...]
> 
>I'd like to emphasize that the code was written entirely from the spec posted
>by Peter Gutmann. I have never seen code of any RSA cipher, including
"RC2". I
>am living, working and programming in the Federal Repulic of Germany,
which is
>neither a part of the United States of America nor subject to the latter's
>legislation or jurisdiction.
> 
>I wish you all the best,
> 
>Daniel Vogelheim
> 
>[There have been further clean-room versions based on my spec, including the
> one in SSLeay (written in Australia) and apparently one from Finland.  Take
> your pick...]
>
>

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: The RC2 debate 
Date: Tue, 22 Apr 1997 18:40:45 -0400
Sender: [email-masked]

> 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]>.  This has also ended up on a 
> number of FTP sites, and I've seen it on at least one CDROM archive.  
> I assume that's enough to qualify it as "widely published".

No, I don't think so.  Neither random FTP sites nor a CDROM archive give 
me any confidence that the specification will be widely available for a 
reasonable amount of time. 

Keith

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: The RC2 debate
Reply-To: [email-masked]
Date: Wed, 23 Apr 1997 10:25:14 (NZST)
Sender: [email-masked]

Since I've had several requests and questions about this (and I'll probably
never hear the end of it otherwise), here's the RC2 clean-room stuff including
the spec.
 
Peter.
 
-- The original message, from a source in the Netherlands --
 
Newsgroups: sci.crypt
From: [email-masked] (Anonymous)
Subject: RC2 source code
Date: 29 Jan 1996 06:38:04 +0100
Organization: Hack-Tic International, Inc.
Message-ID: <[email-masked]>
 
[Reverse-engineered RC2 code]
 
-- My spec for RRC.2, from New Zealand --
 
Newsgroups: sci.crypt
From: [email-masked] (Peter Gutmann)
Subject: Specification for Ron Rivests Cipher No.2
Date: 11 Feb 1996 06:45:03 GMT
Organization: University of Auckland
Message-ID: <[email-masked]>
 
                           Ron Rivest's Cipher No.2
                           ------------------------
 
Ron Rivest's Cipher No.2 (hereafter referred to as RRC.2, other people may
refer to it by other names) is word oriented, operating on a block of 64 bits
divided into four 16-bit words, with a key table of 64 words.  All data units
are little-endian.  This functional description of the algorithm is based in
the paper "The RC5 Encryption Algorithm" (RC5 is a trademark of RSADSI), using
the same general layout, terminology, and pseudocode style.

Notation and RRC.2 Primitive Operations
 
RRC.2 uses the following primitive operations:
 
1. Two's-complement addition of words, denoted by "+".  The inverse operation,
   subtraction, is denoted by "-".
2. Bitwise exclusive OR, denoted by "^".
3. Bitwise AND, denoted by "&".
4. Bitwise NOT, denoted by "~".
5. A left-rotation of words; the rotation of word x left by y is denoted
   x <<< y.  The inverse operation, right-rotation, is denoted x >>> y.
 
These operations are directly and efficiently supported by most processors.

The RRC.2 Algorithm
 
RRC.2 consists of three components, a *key expansion* algorithm, an
*encryption* algorithm, and a *decryption* algorithm.

Key Expansion
 
The purpose of the key-expansion routine is to expand the user's key K to fill
the expanded key array S, so S resembles an array of random binary words
determined by the user's secret key K.
 
Initialising the S-box
 
RRC.2 uses a single 256-byte S-box derived from the ciphertext contents of
Beale Cipher No.1 XOR'd with a one-time pad.  The Beale Ciphers predate modern
cryptography by enough time that there should be no concerns about trapdoors
hidden in the data.  They have been published widely, and the S-box can be
easily recreated from the one-time pad values and the Beale Cipher data taken
from a standard source.  To initialise the S-box:
 
  for i = 0 to 255 do
    sBox[ i ] = ( beale[ i ] mod 256 ) ^ pad[ i ]
 
The contents of Beale Cipher No.1 and the necessary one-time pad are given as
an appendix at the end of this document.  For efficiency, implementors may wish
to skip the Beale Cipher expansion and store the sBox table directly.
 
Expanding the Secret Key to 128 Bytes
 
The secret key is first expanded to fill 128 bytes (64 words).  The expansion
consists of taking the sum of the first and last bytes in the user key, looking
up the sum (modulo 256) in the S-box, and appending the result to the key.  The
operation is repeated with the second byte and new last byte of the key until
all 128 bytes have been generated.  Note that the following pseudocode treats
the S array as an array of 128 bytes rather than 64 words.
 
  for j = 0 to length-1 do
    S[ j ] = K[ j ]
  for j = length to 127 do
    s[ j ] = sBox[ ( S[ j-length ] + S[ j-1 ] ) mod 256 ];
 
At this point it is possible to perform a truncation of the effective key
length to ease the creation of espionage-enabled software products.  However
since the author cannot conceive why anyone would want to do this, it will not
be considered further.
 
The final phase of the key expansion involves replacing the first byte of S
with the entry selected from the S-box:
 
  S[ 0 ] = sBox[ S[ 0 ] ]

Encryption
 
The cipher has 16 full rounds, each divided into 4 subrounds.  Two of the full
rounds perform an additional transformation on the data.  Note that the
following pseudocode treats the S array as an array of 64 words rather than 128
bytes.
 
  for i = 0 to 15 do
    j = i * 4;
    word0 = ( word0 + ( word1 & ~word3 ) + ( word2 & word3 ) + S[ j+0 ] ) <<< 1
    word1 = ( word1 + ( word2 & ~word0 ) + ( word3 & word0 ) + S[ j+1 ] ) <<< 2
    word2 = ( word2 + ( word3 & ~word1 ) + ( word0 & word1 ) + S[ j+2 ] ) <<< 3
    word3 = ( word3 + ( word0 & ~word2 ) + ( word1 & word2 ) + S[ j+3 ] ) <<< 5
 
In addition the fifth and eleventh rounds add the contents of the S-box indexed
by one of the data words to another of the data words following the four
subrounds as follows:
 
    word0 = word0 + S[ word3 & 63 ];
    word1 = word1 + S[ word0 & 63 ];
    word2 = word2 + S[ word1 & 63 ];
    word3 = word3 + S[ word2 & 63 ];

Decryption
 
The decryption operation is simply the inverse of the encryption operation.
Note that the following pseudocode treats the S array as an array of 64 words
rather than 128 bytes.
 
  for i = 15 downto 0 do
    j = i * 4;
    word3 = ( word3 >>> 5 ) - ( word0 & ~word2 ) - ( word1 & word2 ) - S[ j+3 ]
    word2 = ( word2 >>> 3 ) - ( word3 & ~word1 ) - ( word0 & word1 ) - S[ j+2 ]
    word1 = ( word1 >>> 2 ) - ( word2 & ~word0 ) - ( word3 & word0 ) - S[ j+1 ]
    word0 = ( word0 >>> 1 ) - ( word1 & ~word3 ) - ( word2 & word3 ) - S[ j+0 ]
 
In addition the fifth and eleventh rounds subtract the contents of the S-box
indexed by one of the data words from another one of the data words following
the four subrounds as follows:
 
    word3 = word3 - S[ word2 & 63 ]
    word2 = word2 - S[ word1 & 63 ]
    word1 = word1 - S[ word0 & 63 ]
    word0 = word0 - S[ word3 & 63 ]

Test Vectors
 
The following test vectors may be used to test the correctness of an RRC.2
implementation:
 
  Key:      0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
            0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
  Plain:    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
  Cipher:   0x1C, 0x19, 0x8A, 0x83, 0x8D, 0xF0, 0x28, 0xB7
 
  Key:      0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
            0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01
  Plain:    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
  Cipher:   0x21, 0x82, 0x9C, 0x78, 0xA9, 0xF9, 0xC0, 0x74
 
  Key:      0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
            0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
  Plain:    0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
  Cipher:   0x13, 0xDB, 0x35, 0x17, 0xD3, 0x21, 0x86, 0x9E
 
  Key:      0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
            0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F
  Plain:    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
  Cipher:   0x50, 0xDC, 0x01, 0x62, 0xBD, 0x75, 0x7F, 0x31

Appendix: Beale Cipher No.1, "The Locality of the Vault", and One-time Pad for
          Creating the S-Box
 
Beale Cipher No.1.
 
  71, 194,  38,1701,  89,  76,  11,  83,1629,  48,  94,  63, 132,  16, 111,  95,
  84, 341, 975,  14,  40,  64,  27,  81, 139, 213,  63,  90,1120,   8,  15,   3,
 126,2018,  40,  74, 758, 485, 604, 230, 436, 664, 582, 150, 251, 284, 308, 231,
 124, 211, 486, 225, 401, 370,  11, 101, 305, 139, 189,  17,  33,  88, 208, 193,
 145,   1,  94,  73, 416, 918, 263,  28, 500, 538, 356, 117, 136, 219,  27, 176,
 130,  10, 460,  25, 485,  18, 436,  65,  84, 200, 283, 118, 320, 138,  36, 416,
 280,  15,  71, 224, 961,  44,  16, 401,  39,  88,  61, 304,  12,  21,  24, 283,
 134,  92,  63, 246, 486, 682,   7, 219, 184, 360, 780,  18,  64, 463, 474, 131,
 160,  79,  73, 440,  95,  18,  64, 581,  34,  69, 128, 367, 460,  17,  81,  12,
 103, 820,  62, 110,  97, 103, 862,  70,  60,1317, 471, 540, 208, 121, 890, 346,
  36, 150,  59, 568, 614,  13, 120,  63, 219, 812,2160,1780,  99,  35,  18,  21,
 136, 872,  15,  28, 170,  88,   4,  30,  44, 112,  18, 147, 436, 195, 320,  37,
 122, 113,   6, 140,   8, 120, 305,  42,  58, 461,  44, 106, 301,  13, 408, 680,
  93,  86, 116, 530,  82, 568,   9, 102,  38, 416,  89,  71, 216, 728, 965, 818,
   2,  38, 121, 195,  14, 326, 148, 234,  18,  55, 131, 234, 361, 824,   5,  81,
 623,  48, 961,  19,  26,  33,  10,1101, 365,  92,  88, 181, 275, 346, 201, 206
 
One-time Pad.
 
 158, 186, 223,  97,  64, 145, 190, 190, 117, 217, 163,  70, 206, 176, 183, 194,
 146,  43, 248, 141,   3,  54,  72, 223, 233, 153,  91, 210,  36, 131, 244, 161,
 105, 120, 113, 191, 113,  86,  19, 245, 213, 221,  43,  27, 242, 157,  73, 213,
 193,  92, 166,  10,  23, 197, 112, 110, 193,  30, 156,  51, 125,  51, 158,  67,
 197, 215,  59, 218, 110, 246, 181,   0, 135,  76, 164,  97,  47,  87, 234, 108,
 144, 127,   6,   6, 222, 172,  80, 144,  22, 245, 207,  70, 227, 182, 146, 134,
 119, 176,  73,  58, 135,  69,  23, 198,   0, 170,  32, 171, 176, 129,  91,  24,
 126,  77, 248,   0, 118,  69,  57,  60, 190, 171, 217,  61, 136, 169, 196,  84,
 168, 167, 163, 102, 223,  64, 174, 178, 166, 239, 242, 195, 249,  92,  59,  38,
 241,  46, 236,  31,  59, 114,  23,  50, 119, 186,   7,  66, 212,  97, 222, 182,
 230, 118, 122,  86, 105,  92, 179, 243, 255, 189, 223, 164, 194, 215,  98,  44,
  17,  20,  53, 153, 137, 224, 176, 100, 208, 114,  36, 200, 145, 150, 215,  20,
  87,  44, 252,  20, 235, 242, 163, 132,  63,  18,   5, 122,  74,  97,  34,  97,
 142,  86, 146, 221, 179, 166, 161,  74,  69, 182,  88, 120, 128,  58,  76, 155,
  15,  30,  77, 216, 165, 117, 107,  90, 169, 127, 143, 181, 208, 137, 200, 127,
 170, 195,  26,  84, 255, 132, 150,  58, 103, 250, 120, 221, 237,  37,   8,  99

Implementation
 
A non-US based programmer who has never seen any encryption code before will
shortly be implementing RRC.2 based solely on this specification and not on
knowledge of any other encryption algorithms.  Stand by.
 
-- The announcement of the clean-room version, from Germany --
 
Newsgroups: sci.crypt
From: [email-masked] (Daniel Vogelheim)
Subject: RRC.2 implementation available
Date: 18 Feb 1996 01:06:08 GMT
Organization: RWTH -Aachen / Rechnerbetrieb Informatik
Message-ID: <[email-masked]>
 
Hi,
 
I have implemented the RRC.2 cipher and want to make it available to anybody
interested. Since I am new to cryptography the code probably isn't of high
quality by professional measures, though. (I plan to improve it as I learn.)
 
[...]
 
I'd like to emphasize that the code was written entirely from the spec posted
by Peter Gutmann. I have never seen code of any RSA cipher, including "RC2". I
am living, working and programming in the Federal Repulic of Germany, which is
neither a part of the United States of America nor subject to the latter's
legislation or jurisdiction.
 
I wish you all the best,
 
Daniel Vogelheim
 
[There have been further clean-room versions based on my spec, including the
 one in SSLeay (written in Australia) and apparently one from Finland.  Take
 your pick...]

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: The RC2 debate
Cc: [email-masked]
Reply-To: [email-masked]
Date: Wed, 23 Apr 1997 10:04:05 (NZST)
Sender: [email-masked]

>We still have to have a spec that can be referenced.
>
>I personally don't care who wrote the spec, as long as it's published,
>widely available, and the community agrees that it's good enough to use.

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]>.  This has also ended up on a 
number of FTP sites, and I've seen it on at least one CDROM archive.  I assume 
that's enough to qualify it as "widely published".
 
Peter.

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: The RC2 debate 
Date: Tue, 22 Apr 1997 17:53:26 -0400
Sender: [email-masked]

> I don't know if RSADSI can still claim this to be a trade secret.  

We still have to have a spec that can be referenced.

I personally don't care who wrote the spec, as long as it's published,
widely available, and the community agrees that it's good enough to use.

Keith

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: The RC2 debate
Reply-To: [email-masked]
Date: Tue, 22 Apr 1997 10:39:30 (NZST)
Sender: [email-masked]

>It seems pretty clear to me.   Both Jeff Schiller and Keith Moore have stated 
<categorically that RC2, because of its "trade secret" status is not an 
>acceptible algorithm for an IETF standards track document.   They get to 
>decide on that particular issue.   I am fully in agreement with them on this 
>issue.
 
I don't know if RSADSI can still claim this to be a trade secret.  Because of 
the questionable status of RC4, the release of RC2 was handled very carefully 
to make sure it was a genuine clean-room copy, and the whole process was very 
publicly documented to ensure it could be verified by anyone.  First an RC2 
implementation was reverse-engineered, then a text-only specification of the 
algorithm was written by someone on the other side of the planet, and finally 
a third person (back on the other side of the planet again) who had never seen 
the reverse-engineerd RC2 code wrote a new implementation based entirely on 
the text-only specification.  The entire process was documented in postings to 
sci.crypt.  Although IANAL, from what I've read of reverse-engineering this 
should be good enough to withstand scrutiny - in any case a reasonably 
sizeable non-US company which is using the code has had their lawyers look at 
it briefly and is confident they'll win any legal challenge, at least based on 
EU laws which AFAIK are mostly the same as US ones in this regard.
 
Peter.

From: Blake Ramsdell <[email-masked]>
To: "'Ned Freed'" <[email-masked]>, "'Charles Breed'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: S/MIME Export and the IETF
Date: Mon, 21 Apr 1997 14:08:13 -0700
Sender: [email-masked]

And so Steve was right:  "The goals of the IETF are out of step with US
companies' business needs".

I don't know why anyone ever debated it.

The only thing that was ever in scope for me was the interoperability of
any two implementations of S/MIME.  That's it.  The MUST for RC2 40-bit
/ whatever 40-bit is only to accomplish that goal.  I don't know why I
have trouble getting this across.

Bob, you should get your own email address sometime :).

Blake

>-----Original Message-----
>From:	Ned Freed [SMTP:[email-masked]]
>Sent:	Monday, April 21, 1997 10:18 AM
>To:	Charles Breed
>Cc:	[email-masked]
>Subject:	Re: S/MIME Export and the IETF
>
>> "The IETF has to get out of two businesses: (1) worrying about the market
>> share of a few U.S. software companies and (2) interpreting U.S. export
>> control laws.
>
>Hear hear! Charles, I am in complete agreement with this, and moreover I
>would go so far as to recommend that any charter developed for an S/MIME
>working group place these concerns out of scope.
>
>As it happens I'm also a principal in a US software company that would very
>much like to be able to sell strong encryption to the 45% of our customer
>base
>that happens to be outside the US. And mandating strong encryption in S/MIME
>absolutely does hurt us in this regard. However, I am also able to separate
>what's good for the IETF as a whole from what is good for us as a business,
>and
>in my judgement what's good for the IETF isn't what's good for us, at least
>not
>in the short term, so mandatory strong encryption is what I think the IETF
>should mandate in S/MIME.
>
>This issue is entirely separate from the RC* issue, BTW. RC* with 256 bits
>of key is every bit as unacceptable as 40 bits is when it comes to IETF
>confidentiality rules.
>
>				Ned

Date: Mon, 21 Apr 97 09:46:40 
From: "Housley, Russ" <[email-masked]>
To: [email-masked], Raph Levien <[email-masked]>
Subject: Re: The 40-bit debate
Sender: [email-masked]

Raph Levien said:
     I should clarify one other point: even listing at least one exportable 
     algorithm as MUST won't guarantee full interoperability. The remaining 
     issue is RSA key length. Unless something happened to the export regs 
     that I'm not aware of, US-export software is still restricted to 
     512-bit RSA keys. Therefore, this software won't recognize signatures 
     made with unrestricted software, and can't be used to send encrypted 
     messages to unrestricted agents. I'm not sure whether this is still 
     interoperability or not (I'm not trying to be funny here - I think the 
     underlying problem is that we haven't agreed on exactly what 
     "interoperability" means).

The key sizes associated with signatures are not controlled.  The vendor 
must show that the signature cannot be used for key management, but once 
this easy task is accomplished, there are no controlls on signature 
mechanisms.

Russ

From: Steve Hole <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: The RC2 debate
Date: Mon, 21 Apr 1997 14:43:56 -0600 (MDT)
Sender: [email-masked]

It seems pretty clear to me.   Both Jeff Schiller and Keith Moore have 
stated categorically that RC2, because of its "trade secret" status is not 
an acceptible algorithm for an IETF standards track document.   They get 
to decide on that particular issue.   I am fully in agreement with them on 
this issue.

Given a willingness to move ahead, the 5 options listed by Ned are now 
reduced to two options: 

> (1) Drop any trade secret claims for the algorithms used in S/MIME.
> 
> (2) Completely remove them from the S/MIME standard-to-be. It isn't a 
>     question of whether or not it can be required -- in point of fact 
>     you cannot mention these algorithms at all.

The ball is clearly in RSA's court.   Will you or will you not relinquish 
the trade secret status on RC2.   The only possible answers to this 
question are "YES" or "NO".   If the answer is no, then it cannot be 
included in an IETF standards track document.   Once we hear officially 
from RSA on this issue, we can proceed.

---  
Steve Hole			VP,  Research and Development  
The Esys Corporation		EMail: [email-masked]
900 10040 - 104 St.		Phone: 403-424-4922  
Edmonton, AB, Canada		Fax:   403-424-4925  
T5J 0Z6  

Date: Mon, 21 Apr 1997 10:17:51 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: S/MIME Export and the IETF
To: Charles Breed <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> "The IETF has to get out of two businesses: (1) worrying about the market
> share of a few U.S. software companies and (2) interpreting U.S. export
> control laws.

Hear hear! Charles, I am in complete agreement with this, and moreover I
would go so far as to recommend that any charter developed for an S/MIME
working group place these concerns out of scope.

As it happens I'm also a principal in a US software company that would very
much like to be able to sell strong encryption to the 45% of our customer base
that happens to be outside the US. And mandating strong encryption in S/MIME
absolutely does hurt us in this regard. However, I am also able to separate
what's good for the IETF as a whole from what is good for us as a business, and
in my judgement what's good for the IETF isn't what's good for us, at least not
in the short term, so mandatory strong encryption is what I think the IETF
should mandate in S/MIME.

This issue is entirely separate from the RC* issue, BTW. RC* with 256 bits
of key is every bit as unacceptable as 40 bits is when it comes to IETF
confidentiality rules.

				Ned

Date: Mon, 21 Apr 1997 09:39:54 -0700
To: [email-masked]
From: Charles Breed <[email-masked]>
Subject: S/MIME Export and the IETF
Sender: [email-masked]

"The IETF has to get out of two businesses: (1) worrying about the market
share of a few U.S. software companies and (2) interpreting U.S. export
control laws.  

With a strong-encyption S/MIME standard, U.S. developers will support
S/MIME (strong) based upon a new IETF standard and international software
developers will support the S/MIME (strong) based upon the same standard.
On overseas versions, U.S. software companies can ship US/MIME (40-bit).  
If they're worried about losing market share, then they can build their 
client software with a universal API (or better yet, publish the source 
code) so that strong and weak crypto can both be supported.  Thus, when 
you export the program with US/MIME only, overseas developers could 
develop and integrate code based on the strong S/MIME.

So, you're so certain this would be non-exportable???  Why should the IETF
be in the business of determining what's exportable?  As someone here said,
large U.S. corporations routinely get permission to export 128-bit
encyption.  U.S. companies can develop their own strong encyrption plug-ins
to U.S. software company's client software and get permission to export
strong encyption with no sweat.  The Internet users are solving real
intellectual property and trade secret problems and the U.S. government is
fully cooperating with them.  They could care less about the market share
problems of U.S. software companies, who by the way, exist by virtue of
these Internet users.  Does the the IETF exist to solve the legal problems
of a few U.S. software companies or are they trying to solve real problems
that Internet users face every day???

The only course for the IETF is to just do what's technologically sound and
let innovation and the marketplace take its course.  Savvy U.S. software
developers will build API's to their client software (or just distribute
their source code, as any good cryptographic software should) and they and
their legal advisers, not you or the IETF, will make the decision as to
what's exportable.  By requiring a proprietary algorithm or code, the IETF
is in the business of enforcing export control laws AS THOSE LAWS ARE
INTERPRETED BY THE OWNER OF THE PROPRIETATY ALGORITYHM OR CODE.  It's about
time this stops.  Let's reflect upon the charter of the IETF and, if we
remember that we're here for the end users and customers, we'll make the
right decisions."

Bob Kohn, VP Business Dev. PGP, Inc.
[email-masked]

From: Keith Moore <[email-masked]>
To: "Paul E. Hoffman" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: The 40-bit debate 
Date: Sat, 19 Apr 1997 00:22:06 -0400
Sender: [email-masked]

> >Pardon me for being blunt, but from a user's perspective, having a
> >single protocol with two different profiles is no different from having
> >two different protocols.
> 
> No need for pardon; in fact, I think thanks are in order. This is probably
> the most succint statement yet made on the issue. The protocols may have a
> high level of overlap, but they don't have interoperability, and are thus
> separate.

Yep.  That's the best way to think about it.  Though if the two protocols
share a lot of common code, it's clearly useful for products that
want to implement both protocols.

Keith

Date: Fri, 18 Apr 1997 15:51:03 -0700
To: [email-masked]
From: "Paul E. Hoffman" <[email-masked]>
Subject: Re: The 40-bit debate
Sender: [email-masked]

At 12:14 PM -0700 4/18/97, Raph Levien wrote:
>Paul Hoffman writes:
>
>> It's clear to me that some people who are replying on this list haven't
>> read the draft since they didn't know that the draft has two profiles, a
>> "restricted" one that has 40-bit only and an "unrestricted" one that has
>> both 40-bit and tripleDES. Section 2.6 of the draft clearly says when the
>> restricted profile should be used, and that's pretty damn rarely.
>
>I have a few problems with this. 2.6.3 appears to give users the choice
>between incurring the "risk of failed decryption" and defaulting to
>RC2/40. Again, I'm not sure we can claim "interoperability" in the
>former case.

Note that a sender or receiver using the unrestricted profile MUST be able
to encrypt *and* decrypt the restricted algorithm. (See the list at the
beginning of Section 2.6.2.) Thus, interoperability is assured in 2.6.3, if
and only if the unrestricted client really does do both halves of the
restricted algorithm.

>I don't mean to whine, but I am quite curious why my earlier proposal
>(in which the default algorithm was dependent on the length of the
>recipient's RSA key) was abandoned. This proposal maximized
>interoperability in the case where one of the agents was restricted, yet
>prevented RC2/40 from being the default choice in the case where neither
>agents were restricted.

This was my decision, and I'm willing to turn around an put it back in if
the group wants it. The reason I took it out is that your heuristic is both
time-dependant and law-dependant, and it seemed wrong to codify this in a
long-lasting spec.

- What if the US government starts allowing longer RSA keys but not
stronger encryption algorithms?
- What if the US government decides that 56 bit DES is OK, and allows
slightly longer RSA keys to match? The current heuristic jumps from 40-bit
RC/2 to full tripleDES.
- What if some other government, using broken logic similar to the US,
allows strong encryption algorithms but only shorter keys?

Again, I'm open to arguments on putting the key-length heuristic back in,
but I'd want to feel that the rules in the spec all would be valid five and
maybe ten years from now. I'm also willing to put in other heuristics that
we all think will pass the test of time.

>Section 2.6.3.3 also invites protocol attacks:
>. . .
>It is not stated here how the sending agent should determine whether it
>has receieved "at least one message from the recipient." Does it simply
>use the e-mail address in the "From:" header field to identify the
>sender? Or does it require a trusted signature as well?

Good point. I'll rewrite this to state that only trusted signatures should
be used to pass the test in this section.

>Pardon me for being blunt, but from a user's perspective, having a
>single protocol with two different profiles is no different from having
>two different protocols.

No need for pardon; in fact, I think thanks are in order. This is probably
the most succint statement yet made on the issue. The protocols may have a
high level of overlap, but they don't have interoperability, and are thus
separate.

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

Date: Fri, 18 Apr 1997 18:37:53 -0400
From: Uri Blumenthal <[email-masked]>
To: [email-masked] (David P. Kemp)
Cc: [email-masked]
Subject: Re: Other exportable 40-bit algorithms
Reply-To: [email-masked]
Sender: [email-masked]

>>>>> "David" == David P Kemp <[email-masked]> writes:

    David> Uri, Are you familiar enough with the SSL/TLS technique of
    David> creating export keys (hashing 40 secret bits with 88 salt
    David> bits) to state whether it is covered by the CDMF patent?

Shame on me - no I am not familiar with how TLS is doing this.
Also - I have learned tha common sense usually has little to
do wrt. patent applicability. Not being a lawyer - I have
no idea whatsoever, whether CDMF patent does or does not
apply.

Regards,                   [To reply, remove "NOSPAM!" from the 
Uri                         "Reply-To:" field]
-=-=-==-=-=-		[email-masked]
<Disclaimer>

Date: Fri, 18 Apr 97 12:48:16 
From: "Housley, Russ" <[email-masked]>
To: [email-masked], Blake Ramsdell <[email-masked]>
Subject: Re: Other exportable 40-bit algorithms
Sender: [email-masked]

All:

I have just returned from a meeting with the Export Control office at NSA.  
I raised this question, and was encouraged by the reponse.  It is possible 
for us to select another 40-bit algorithm (perhaps, DES-40 as suggested in 
a previous note by Dave Kemp), and get that algorithm approved for 
expedited export when it is used in conjunction with the our protocol.

A similar arrangement has already been made concerning the algorithms used 
in the SET payment protocol.

Russ

______________________________ Reply Separator _________________________________
Subject: Other exportable 40-bit algorithms
Author:  Blake Ramsdell <[email-masked]> at internet
Date:    4/17/97 3:25 PM

Is there any alternative to RC2 40-bit that meets US export requirements 
for symmetric algorithms, and does not require you to:

1. Wait an eternity for export approval
2. Register every sale of a product to a non-US/Canada 
company/individual with the government
3. Require you to implement escrow features in your product

RC2 40-bit enjoys both an expedited export approval (I seem to remember 
ours being a month) and does not have the burden of reporting individual 
unit sales with the government.  Is this true of CAST 40-bit or DES-40?

Blake

Date: Fri, 18 Apr 97 13:21:53 
From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Subject: Re: The RC2 debate
Sender: [email-masked]

Paul E Hoffman <[email-masked]> wrote:
> I'd like to second the motion to split the RC2/40 discussion 
> into two parts. Please note the subject of this part, and 
> reply with this subject if you want to talk about whether or 
> not the S/MIME spec should have a MUST or a SHOULD that 
> includes RC2 encryption.

S/MIME MAY include RC2.
RC2 should not be a MUST.

Date: Fri, 18 Apr 1997 12:14:58 -0700
From: Raph Levien <[email-masked]>
To: [email-masked]
Subject: Re: The 40-bit debate
Sender: [email-masked]

Blake Ramsdell wrote:

> We should cut and paste this whole debate from the IMC Resolving
> Security mailing list last year :).

Ouch! I feel like we've been through this before, many times before.
Nonetheless, I still want to respond to a number of statements here
which I feel to be inaccurate.

I'll start with Laurence Lundblade:

> The US export law prevents vendors (freeware, shareware or commercial) from
> meeting the user's need of strong, globally interoperable crypto.

This really needs to be clarified. The US export law prevents _US_
vendors from meeting the user's need of strong, globally interoperable
crypto. At present, there is nothing stopping a mixture of US and non-US
vendors from meeting these needs. In this scenario, the US vendors would
be barred from exporting their product. Non-US vendors, on the other
hand, would be able to supply the entire world.

This would be the case if there were any algorithm other than the 40-bit
ones listed as MUST.

I should clarify one other point: even listing at least one exportable
algorithm as MUST won't guarantee full interoperability. The remaining
issue is RSA key length. Unless something happened to the export regs
that I'm not aware of, US-export software is still restricted to 512-bit
RSA keys. Therefore, this software won't recognize signatures made with
unrestricted software, and can't be used to send encrypted messages to
unrestricted agents. I'm not sure whether this is still interoperability
or not (I'm not trying to be funny here - I think the underlying problem
is that we haven't agreed on exactly what "interoperability" means).

Paul Hoffman writes:

> It's clear to me that some people who are replying on this list haven't
> read the draft since they didn't know that the draft has two profiles, a
> "restricted" one that has 40-bit only and an "unrestricted" one that has
> both 40-bit and tripleDES. Section 2.6 of the draft clearly says when the
> restricted profile should be used, and that's pretty damn rarely.

I have a few problems with this. 2.6.3 appears to give users the choice
between incurring the "risk of failed decryption" and defaulting to
RC2/40. Again, I'm not sure we can claim "interoperability" in the
former case.

I don't mean to whine, but I am quite curious why my earlier proposal
(in which the default algorithm was dependent on the length of the
recipient's RSA key) was abandoned. This proposal maximized
interoperability in the case where one of the agents was restricted, yet
prevented RC2/40 from being the default choice in the case where neither
agents were restricted.

Section 2.6.3.3 also invites protocol attacks:

> If a sending agent using the unrestricted profile has not received a
> set of capabilities from the intended recipient for the message, but
> the sending agent has received at least one message from the
> recipient, and the last message received used RC2 in CBC mode at a key
> size of 40 bits (indicating that the recipient only uses the
> restricted profile), the outgoing message SHOULD use RC2 in CBC mode
> at a key size of 40 bits if the sending agent reasonably expects the
> recipient to be able to decrypt the message.

It is not stated here how the sending agent should determine whether it
has receieved "at least one message from the recipient." Does it simply
use the e-mail address in the "From:" header field to identify the
sender? Or does it require a trusted signature as well?

Let's say the sending agent is Alice, the recipient is Bob, and the
attacker is Mallet. In the first case, all Mallet would need to do is
send mail to Alice saying "From: Bob" and encrypt it using RC2/40. Then,
when Alice sent mail to Bob, rule 2.6.3.3 would click in, and the
message would also be encrypted with RC2/40. In the second case, there's
no language in this section that would prevent replay attacks. If Bob
had ever generated a signed RC2/40 message (say, by mistake), then
Mallet could forward that message to Alice, which would cause her to use
RC2/40 in her messages to Bob until she received the next signed
non-RC2/40 message from Bob.

But the second case seems to me to be moot, because if we're requiring
trusted signatures, then Alice should be able to expect a signed (and
timestamped) symmetric algorithm capabilities field in the message, as
well.

Finally, Steve Dusse writes:

> I agree with your characterization of the issues and I will attempt to
> initiate the separation of protocol from profiling if that seems like an
> acceptable path to IETF involvement in S/MIME.

Pardon me for being blunt, but from a user's perspective, having a
single protocol with two different profiles is no different from having
two different protocols. Going this route means trading interoperability
for the privilege of US companies to export software and still have the
S/MIME label. I'm not arguing against this choice, just asking that it
be made clear exactly what's being proposed.

To sum up, I see two choices:

1) Include a strong, non-proprietary algorithm as MUST, and specify that
sending agents MUST usae this algorithm when nothing further is known
about the recipient's capabilities.

2) Define two profiles. Only guarantee full interoperability when the
two agents are in the same profile.

Choice (1) would be a strong, globally interoperable solution, but would
make it impossible for US vendors to export a product with the S/MIME
label. As such, it is an invitation to non-US vendors to walk away with
a significant market share. I can see why the US vendors currently in
control of S/MIME would prefer not to see this happen. However, the IETF
has a rich tradition of making design decisions based on the technical
superiority of the resulting protocols, rather than to favor the
business interests of individual companies.

It will be interesting to see how this gets resolved (this time around,
anyway :-).

Raph

From: Steve Dusse <[email-masked]>
To: "'Keith Moore'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Alternative symmetric algorithm freely available for IETFS/MIME (re: RC2 licensing). 
Date: Fri, 18 Apr 1997 11:12:40 -0700
Sender: [email-masked]

Keith,

I agree with your characterization of the issues and I will attempt to
initiate the separation of protocol from profiling if that seems like an
acceptable path to IETF involvement in S/MIME.
>
>BTW, your characterization of the difference as "non-business" vs. 
>"business-needs-centric" is ... misleading at best.  

I disagree.  Perhaps a clarification is in order.  By US companies'
business needs, I am referring to US-based software developers.  Roughly
speaking, US software companies (my company excepted) derive 50% of
their revenue from products that are exported.  Export of product with
encryption is tightly controlled.  RC2 was created specifically to
address this business issue, no other.

>Let us speak plainly, and call it what it is: "reasonably secure crypto" 
>vs. "crypto weak enough to pass US current export regulations."

Fair enough.

-steve
>

Date: Fri, 18 Apr 1997 09:30:01 -0700
To: [email-masked]
From: "Paul E. Hoffman" <[email-masked]>
Subject: RE: The 40-bit debate
Sender: [email-masked]

I guess I should have been more specific when I started this thread. What I
should have said was:

After reading the current draft (which is available at
<http://www.imc.org/draft-dusse-smime-msg>), please use the above subject
line when replying about whether or not the S/MIME spec should have a MUST
or a SHOULD that includes 40-bit encryption.

It's clear to me that some people who are replying on this list haven't
read the draft since they didn't know that the draft has two profiles, a
"restricted" one that has 40-bit only and an "unrestricted" one that has
both 40-bit and tripleDES. Section 2.6 of the draft clearly says when the
restricted profile should be used, and that's pretty damn rarely.

Now, I'm not saying that the current draft is the best solution,
particularly since profiles have caused horrible problems for IETF-blessed
email in the past, but I believe that this can be worked out for S/MIME.

So, everyone, please read the draft, particularly Section 2.6 and all of
its subsections, and continue to comment on the 40-bit MUST/SHOULD/MAY
issue.

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

Date: Fri, 18 Apr 1997 08:28:17 -0700
To: [email-masked]
From: Laurence Lundblade <[email-masked]>
Subject: RE: The 40-bit debate - user's needs
Sender: [email-masked]

I think we can put the "US company needs" aside for a moment and look at it
from the point of view of the user. The result is more or less the same.
The US export law prevents vendors (freeware, shareware or commercial) from
meeting the user's need of strong, globally interoperable crypto.

So the question for me, is what is the best attack that will get the law
changed, or allow us to get around it?  The law is the real problem, not
one company's desire to make money. The fact that the only algorithm
approved for export is IPR of a particular company is sort of an ironic
twist to this debate.

I suspect the way to get the law changed, is to create public opinion which
will in turn put pressure on our legislators. The argument used thus far is
that the law is "bad for US business".  I don't have the inside track on
the politics, but it seems that has had mixed results. So what are the
scenarios for public opinion given our two choices to doing 40 bit or not?

If we do 40 bit, then we're likely to see the CNN headline and S/MIME may
get a black eye. Can the politics be twisted to blame this on the US
government? Privacy is certainly an issue the public is sensitive to.

If we only do strong with no export, I expect implementations to show up
internationally that will interoperate with US implementations. Some US
implementations might escape the country too.  I'm not sure where the
pressure comes from other, than documenting the lost sales.

I suspect these arguments are pretty incomplete due to my lack
understanding of all the politics, but hopefully approaching the problem of
changing the law for the sake of users around the world is a useful
alternative to the current debate.

LL

Date: Fri, 18 Apr 1997 09:39:29 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Other exportable 40-bit algorithms
Sender: [email-masked]

> From: Uri Blumenthal <[email-masked]>
> 
> Yes for CDMF (IBM-patented, clever reducing the key strength
> 	to 40 bits, as opposite to simply accepting a 40-bit
> 	key only from a user).

> There is no "DES-40" per se, unless you mean CDMF; to the best
> of my knowledge.

Uri,
  Are you familiar enough with the SSL/TLS technique of creating export
keys (hashing 40 secret bits with 88 salt bits) to state whether it
is covered by the CDMF patent?

The SSL technique has obviously gotten export approval, and has received
some level of cryptographic scrutiny within the SSL/TLS community, and
I've heard no mention of it being encumbered.

        dpk

From: [email-masked]
Date: Fri, 18 Apr 1997 10:26:15 GMT
CC: [email-masked]
Subject: RE: The 40-bit debate
To: Blake Ramsdell <[email-masked]>
Sender: [email-masked]

A lot of this discussion seems to be aimed at:
1.	Protecting RSA's "investment" in S/MIME

2.	Protecting US companies from international competion.

Perhaps we could specify a 2 level spec ? :
	Level 1 : Must implement a 40 bit key (using DES or whatever)
	Level 2 : Incorporates Level 1 *and* must implement a 128+ bit key using
<xyz>

If we where being honest we could label it "Insecure/MIME" & "Secure/MIME"
<g>

This way everybody would have a base level of compatibility, US companies
could sell S/MIME in the US and export I/MIME (basically what happens now),
Non-US companies could sell S/MIME everywhere plus exporting to the US.

The only loser would be the US companies who can't export S/MIME (a
ridiculous situation).

I would be perfectly happy with that.
--
Lindsay Mathieson
Black Paw Communications

From: [email-masked]
Date: Fri, 18 Apr 1997 10:26:27 GMT
CC: [email-masked]
Subject: Re: Alternative symmetric algorithm freely availableforIETFS/MIME (re: RC2 licensing).
To: Keith Moore <[email-masked]>
Sender: [email-masked]

> will not and
>cannot be compatible with existing S/MIME implementations -- at least 
>not 
>unless/until there is a RC2 specification available for public 
>review.

Just because a few companies (e.g. MS & Netscape) have jumped the gun in
implementing S/MIME before its finished is no reason lock RC2 into the spec
--
Lindsay Mathieson
Black Paw Communications
	Using MailCat Beta for Win32 Beta Vs 2.0.0.3, on April 18, 1997, in Win95
4.0
Checkout the latest (and greatest <G>) mail client, MailCat at:
	http://www.powerup.com.au/~lindsay

To: [email-masked]
Subject: What's wrong with this format??
Date: Fri, 18 Apr 1997 10:58:48 +0200
From: "Frederik H. Andersen" <[email-masked]>
Sender: [email-masked]

--==_Exmh_-1189929512P
Content-Type: text/plain; charset=us-ascii

Hi!

[email-masked] said:
> The IETF S/MIME Working Group is chartered with defining a  standard
> method to send and receive secure MIME messages  that interoperate
> globally.  The group will place particular  emphasis on the need for
> strong cryptography based on open and publicly available algorithms.

If this is the charter, what is wrong with the format of this mail?
That is RFC2015? 

Can't that be used as a MUST profile or do you all feel that it is too
PGP specific (althoug this IS the international standard of use today!)

I don't quite see why someting like RFC2015 or other relatives to RFC1847
can't be used?

/Frederik

-- 

------------------------------------------------------------------
Frederik H. Andersen            Phone:  +45 42 84 50 11           
Dansk Data Elektronik A/S       Fax:    +45 42 84 52 20           
Herlev Hovedgade 199            Email:  [email-masked] (MIME accepted)
DK-2730 Herlev, DENMARK
PGP Fingerprint:  6B BC FB 45 E4 69 CE A2  63 E1 62 1F 0C 65 C2 E4
------------------------------------------------------------------

	

--==_Exmh_-1189929512P
Content-Type: application/pgp-signature

--==_Exmh_-1189929512P--

To: Blake Ramsdell <[email-masked]>
Cc: [email-masked]
Subject: Re: The 40-bit debate 
Date: Fri, 18 Apr 1997 16:55:28 +1000
From: Scott Merrilees <[email-masked]>
Sender: [email-masked]

>The only 40-bit debate that exists in my mind is how to make sure that
>every client has the ability to encrypt and decrypt messages to and from
>any S/MIME client.  And unfortunately, this means mandating the ability
>to encrypt and decrypt using a 40-bit key.  Using 40-bit encryption
>would meet this (almost) working group's goal of having an interoperable
>standard, and satisfy the needs of US S/MIME companies that would like
>to export their products.

Instead of using 40bit RC2 to provide an illusion of security, why not
ship using the identity algorithm, xor with 0, named 'No Security',
and be done with it.  At least that way those people with out the
desire to know any technical details will not be deluded into thinking
they are making a secure exchange.  This will have the advantage of
being exportable.

Sm

From: Blake Ramsdell <[email-masked]>
To: "'Raph Levien'" <[email-masked]>
Cc: "'Paul E. Hoffman'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Alternative symmetric algorithm freely availableforIETFS/MIME (re: RC2 licensing).
Date: Thu, 17 Apr 1997 23:30:16 -0700
Sender: [email-masked]

We should cut and paste this whole debate from the IMC Resolving
Security mailing list last year :).

There are currently two profiles in the S/MIME spec.  A "RESTRICTED"
profile which specifies 40-bit RC2 as a MUST for encryption and
decryption, and an "UNRESTRICTED" profile which specifies 40-bit RC2 and
triple-DES as a MUST for encryption and decryption.

Certainly, if the spec is changed to have only triple-DES, then any two
compliant applications will be able to interoperate (I learned a cool
word from Ned one time:  "axiomatic".  This is axiomatic.  Even if the
spec didn't change, any two compliant applications would be able to
interoperate).  I probably used the cool word wrong, but you get my
point.

This leaves the US export-restricted crowd out of the party.  I've
started this particular rant over on the 40-bit thread, so go over there
to discuss that one.

Blake

>-----Original Message-----
>From:	Raph Levien [SMTP:[email-masked]]
>Sent:	Thursday, April 17, 1997 11:12 PM
>To:	Blake Ramsdell
>Cc:	'Paul E. Hoffman'; [email-masked]'
>Subject:	RE: Alternative symmetric algorithm freely availableforIETFS/MIME
>(re: RC2 licensing).
>
>
>
>On Thu, 17 Apr 1997, Blake Ramsdell wrote:
>
>> Yes, I understand that two *particular* implementations can
>> interoperate.  But can *any* two implementations interoperate?  No.
>> Because of US export regulation, you can't possibly answer that question
>> yes, because there will be a vendor that does not implement the
>> export-only algorithm unless that algorithm is labeled MUST.
>> 
>> It would be ridiculous for me to say that you had no interoperability at
>> all -- there is always "identity" interoperability with your own product
>> (I hope!).  I'm sorry if my language wasn't precise.  Of course, I may
>> have been trying to be ridiculous also -- it happens :).
>
>I still don't agree with you. If the IETF specifies (say) Triple-DES as a 
>MUST algorithm, then *any* two implementations would be able to 
>interoperate. It's just not the case that there would be any US 
>exportable implementations of S/MIME. Thus, there would be no reason for 
>a sending implementation to use an export-only algorithm.
>
>Raph
>

From: Blake Ramsdell <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: The 40-bit debate
Date: Thu, 17 Apr 1997 23:28:51 -0700
Sender: [email-masked]

The only 40-bit debate that exists in my mind is how to make sure that
every client has the ability to encrypt and decrypt messages to and from
any S/MIME client.  And unfortunately, this means mandating the ability
to encrypt and decrypt using a 40-bit key.  Using 40-bit encryption
would meet this (almost) working group's goal of having an interoperable
standard, and satisfy the needs of US S/MIME companies that would like
to export their products.

I understand the "40 bits sux" argument and all the other
fist-and-lightning-bolt / my-lock-my-key / golden-key / whatever
opinions.  The simple fact is, just because it's required, doesn't mean
you are required to use it if you can use something else.  And just
because you use it, doesn't mean that you can't put up a big warning
screen that says "WARNING:  THIS MESSAGE IS ABOUT TO BE SENT USING
40-BIT ENCRYPTION.  IT HAS BEEN THEORIZED THAT YOU COULD BUILD A REALLY
BIG COMPUTER THAT CAN DECRYPT IT REALLY QUICKLY, BUT NO ONE HAS REALLY
DONE IT YET, OR AT LEAST THEY HAVEN'T ADMITTED TO IT.  ACTUALLY, IAN
BROKE A 40-BIT KEY IN ABOUT THREE HOURS, BUT I THINK HE USED MORE THAN
ONE MACHINE AND HE SKIPPED LUNCH."

The point is, that the user has the CHOICE to read a message that came
from some dumb, crappy export-only version of some wanker American's
product, and the user has the CHOICE to send a message back to that same
person.  This is most easily accomplished by having a 40-bit algorithm
specified as a MUST in the spec.

Some of the wanker American products, by the way, are from pretty
high-volume companies.  We can certainly dump 40-bit out of the MUST,
but at that point, you have just broken interoperability with those
products.

And just because it isn't a MUST in the spec, doesn't mean that people
won't implement it, so the moral argument against 40-bit encryption is
moot.  They're (we're) gonna do it anyway.  We're not misleading our
customers -- we tell them flat-out about the export limitations and the
relative weakness of 40-bit keys are.  If they don't like it, then they
go to another (presumably non-US) vendor that can give them what they
want.  They're not stupid.

Blake

>-----Original Message-----
>From:	Paul E. Hoffman [SMTP:[email-masked]]
>Sent:	Thursday, April 17, 1997 7:48 PM
>To:	[email-masked]
>Subject:	The 40-bit debate
>
>I'd like to second the motion to split the RC2/40 discussion into two
>parts. Please note the subject of this part, and reply with this subject if
>you want to talk about whether or not the S/MIME spec should have a MUST
>or a SHOULD that includes 40-bit encryption.
>
>--Paul E. Hoffman, Director
>--Internet Mail Consortium
>
>

Date: Thu, 17 Apr 1997 23:12:09 -0700 (PDT)
From: Raph Levien <[email-masked]>
To: Blake Ramsdell <[email-masked]>
cc: "'Paul E. Hoffman'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Alternative symmetric algorithm freely availableforIETFS/MIME (re: RC2 licensing).
Sender: [email-masked]

On Thu, 17 Apr 1997, Blake Ramsdell wrote:

> Yes, I understand that two *particular* implementations can
> interoperate.  But can *any* two implementations interoperate?  No.
> Because of US export regulation, you can't possibly answer that question
> yes, because there will be a vendor that does not implement the
> export-only algorithm unless that algorithm is labeled MUST.
> 
> It would be ridiculous for me to say that you had no interoperability at
> all -- there is always "identity" interoperability with your own product
> (I hope!).  I'm sorry if my language wasn't precise.  Of course, I may
> have been trying to be ridiculous also -- it happens :).

I still don't agree with you. If the IETF specifies (say) Triple-DES as a 
MUST algorithm, then *any* two implementations would be able to 
interoperate. It's just not the case that there would be any US 
exportable implementations of S/MIME. Thus, there would be no reason for 
a sending implementation to use an export-only algorithm.

Raph

From: Keith Moore <[email-masked]>
To: Blake Ramsdell <[email-masked]>
cc: "'Paul E. Hoffman'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Alternative symmetric algorithm freely availableforIETFS/MIME (re: RC2 licensing). 
Date: Fri, 18 Apr 1997 01:46:11 -0400
Sender: [email-masked]

> I understand that there is a faction that says that RC2 40-bit should
> just be changed from MUST to SHOULD.  This will cause a lack of
> interoperability.  I further understand that there is a faction that
> says that RC2 should be removed completely from the algorithm suite.
> This will also cause a lack of interoperability.

That's exactly right: the minimum implementation for "Internet Standard 
S/MIME"  (ignoring the trademark issues for the moment)  will not and
cannot be compatible with existing S/MIME implementations -- at least not 
unless/until there is a RC2 specification available for public review.
To do otherwise would be fundamentally incompatible with the Internet 
Standards process.

On the other hand, nothing says that "Internet Standard S/MIME" products 
can't also include the ability to interoperate with "S/MIME classic" 
as long as RSA is willing to license such implementations.

Keith

From: Keith Moore <[email-masked]>
To: "Paul E. Hoffman" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: The 40-bit debate 
Date: Fri, 18 Apr 1997 01:34:23 -0400
Sender: [email-masked]

> Please note the subject of this part, and reply with this subject if
> you want to talk about whether or not the S/MIME spec should have a MUST
> or a SHOULD that includes 40-bit encryption.

The S/MIME spec can specify a way to do 40-bit crypto if this WG wants 
it to do so, and can even specify that implementations "MUST" (or "SHOULD")
implement it.

However,

+ any MUST or SHOULD algorithm MUST be published and available on 
  fair and nondiscriminatory terms  (this is from RFC 2026)

+ (IMHO) the S/MIME spec will not be of standards-track quality
  unless it also specifies a "MUST implement" algorithm and key 
  length compatible with the recommendations of RFC 1984.  

Keith

From: Blake Ramsdell <[email-masked]>
To: "'Raph Levien'" <[email-masked]>
Cc: "'Paul E. Hoffman'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Alternative symmetric algorithm freely availableforIETFS/MIME (re: RC2 licensing).
Date: Thu, 17 Apr 1997 22:19:53 -0700
Sender: [email-masked]

Yes, I understand that two *particular* implementations can
interoperate.  But can *any* two implementations interoperate?  No.
Because of US export regulation, you can't possibly answer that question
yes, because there will be a vendor that does not implement the
export-only algorithm unless that algorithm is labeled MUST.

It would be ridiculous for me to say that you had no interoperability at
all -- there is always "identity" interoperability with your own product
(I hope!).  I'm sorry if my language wasn't precise.  Of course, I may
have been trying to be ridiculous also -- it happens :).

Blake

>-----Original Message-----
>From:	Raph Levien [SMTP:[email-masked]]
>Sent:	Thursday, April 17, 1997 10:00 PM
>To:	Blake Ramsdell
>Cc:	'Paul E. Hoffman'; [email-masked]'
>Subject:	RE: Alternative symmetric algorithm freely availableforIETFS/MIME
>(re: RC2 licensing).
>
>
>
>On Thu, 17 Apr 1997, Blake Ramsdell wrote:
>
>> I understand that there is a faction that says that RC2 40-bit should
>> just be changed from MUST to SHOULD.  This will cause a lack of
>> interoperability.  I further understand that there is a faction that
>> says that RC2 should be removed completely from the algorithm suite.
>> This will also cause a lack of interoperability.
>
>These statements are simply not true. There is nothing that prevents a 
>non-US company from developing a product containing strong crypto. In 
>fact, for SSL, this has already been done. There is also an independent 
>implementation of PGP.
>
>RC2 may actually make interoperability worse, because companies may need
>to license the RC2 code from RSA to be 100% kosher, and the US may
>prohibit RSA from exporting this license. 
>
>What will really kill interoperability for sure is splitting S/MIME into 
>different profiles.
>
>Raph

From: Keith Moore <[email-masked]>
To: "Paul E. Hoffman" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: The RC2 debate 
Date: Fri, 18 Apr 1997 01:19:21 -0400
Sender: [email-masked]

> Please note the subject of this part, and reply with this subject if
> you want to talk about whether or not the S/MIME spec should have a MUST
> or a SHOULD that includes RC2 encryption.

I think the correct word is "MAY", or perhaps even less -- simply
have the spec do nothing more than document the RC2 algorithm-id,
and put the profile that uses RC2 in a separate document.

So long as RC2 remains proprietary, I can't even see making it a "SHOULD".

My reasoning here is entirely due to the status of RC2 as a trade secret, 
and has nothing to do with key lengths.

Keith

Date: Thu, 17 Apr 1997 21:59:46 -0700 (PDT)
From: Raph Levien <[email-masked]>
To: Blake Ramsdell <[email-masked]>
cc: "'Paul E. Hoffman'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Alternative symmetric algorithm freely availableforIETFS/MIME (re: RC2 licensing).
Sender: [email-masked]

On Thu, 17 Apr 1997, Blake Ramsdell wrote:

> I understand that there is a faction that says that RC2 40-bit should
> just be changed from MUST to SHOULD.  This will cause a lack of
> interoperability.  I further understand that there is a faction that
> says that RC2 should be removed completely from the algorithm suite.
> This will also cause a lack of interoperability.

These statements are simply not true. There is nothing that prevents a 
non-US company from developing a product containing strong crypto. In 
fact, for SSL, this has already been done. There is also an independent 
implementation of PGP.

RC2 may actually make interoperability worse, because companies may need
to license the RC2 code from RSA to be 100% kosher, and the US may
prohibit RSA from exporting this license. 

What will really kill interoperability for sure is splitting S/MIME into 
different profiles.

Raph

From: Blake Ramsdell <[email-masked]>
To: "'Paul E. Hoffman'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Alternative symmetric algorithm freely availableforIETFS/MIME (re: RC2 licensing).
Date: Thu, 17 Apr 1997 21:43:36 -0700
Sender: [email-masked]

I wonder how many non-mail client software companies would want to
implement and export S/MIME products?

Perhaps I was overly broad in my statement that "US companies need to
sell products outside the US and Canada", and I should have said that
"US companies that want to implement S/MIME need to have the ability to
sell products outside the US and Canada".  Software is an international
business.

The *teeny number of companies* is 100% of the current and announced
S/MIME vendor market in the US.  Every one of them sells outside of the
US and Canada.  Small in number compared to the number of companies in
the US, granted.  But it is 100% of the US market that is providing
S/MIME.

I understand that there is a faction that says that RC2 40-bit should
just be changed from MUST to SHOULD.  This will cause a lack of
interoperability.  I further understand that there is a faction that
says that RC2 should be removed completely from the algorithm suite.
This will also cause a lack of interoperability.

This is why I don't differentiate between the two -- the outcome is
exactly the same.  This is also why I have asked others to propose
alternative US exportable algorithms so that we can keep an exportable
algorithm in the MUST section, and thus have a minimum level of
interoperability.  The only ones who have to use it are the ones who are
forced to.

If you have an idea as to how this debate can continue in an open forum
that is more to your liking, let me know.  I'm just trying to figure out
how to fulfill the proposed charter of this working group which
specifies interoperability.

Blake

>-----Original Message-----
>From:	Paul E. Hoffman [SMTP:[email-masked]]
>Sent:	Thursday, April 17, 1997 7:46 PM
>To:	[email-masked]
>Subject:	RE: Alternative symmetric algorithm freely availableforIETFS/MIME
>(re: RC2 licensing).
>
>At 6:56 PM -0700 4/17/97, Blake Ramsdell wrote:
>>Consider
>>the following:
>>
>>1. US companies need to sell products outside the US and Canada
>
>Let's be a bit more specific here. *Some* US companies need to sell
>products outside the US and Canada (and Mexico, by the way...). Not all of
>them. The ones you are talking about are companies that create mail client
>software. They are a teeny minority of US companies.
>
>>2. The current discussion about removing RC2 40-bit is about removing
>>the necessary component from the specification that would allow this
>
>Not necessarily true. Some people would like to remove RC2/40 altogether,
>others would prefer to move it to SHOULD or possibly just a list known,
>widely-deployed algorithms. I hear no consensus yet, which isn't surprising
>given the topic.
>
>>In any case, this is the business need, and it appears that the IETF
>>wants to head the spec in a different direction.
>
>Wrong and wrong.
>
>- It is a business need *for a teeny number of companies*. The vast
>majority of US/Canada/Mexico companies have a business need for reliable,
>interoperable, secure email. If the IETF can get that with RC2/40, great.
>If not, the IETF must listen to the needs of all businesses and still come
>up with a spec for reliable, interoperable, secure email.
>
>- "The IETF" doesn't speak with one voice, and thinking that a handful of
>comments on one mailing list over two days reflects the voice of the IETF
>is just plain silly. The debate is only begun, and not very well I might
>add.
>
>--Paul E. Hoffman, Director
>--Internet Mail Consortium
>
>

From: Keith Moore <[email-masked]>
To: Steve Dusse <[email-masked]>
cc: "'Keith Moore'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Alternative symmetric algorithm freely available for IETFS/MIME (re: RC2 licensing). 
Date: Fri, 18 Apr 1997 00:39:05 -0400
Sender: [email-masked]

> Keith makes this point rather succintly.  If there is agreement, then I
> will stand by my earlier conviction;  the goals of the IETF are out of
> step with US companies' business needs.  As such, we should find a way
> to separate the non-business protocol portions of the S/MIME spec from
> the US business-needs-centric profiling information.

Seems like US companies need strong encryption as much as anyone else.

Or if by "US companies' business needs" you really mean "the marketing
concerns of US purveyors of crypto products", then understand this very 
clearly: the IETF exists to make technical recommendations for the 
Internet community, NOT to cater to the marketing concerns of US companies.

As for separating the specs: yes, I agree.  The standard needs to specify
sufficiently strong algorithms for the "must-implement" profile, but I know
of no reason why a separate informational RFC cannot specify a different 
profile for those who choose to use it.

BTW, your characterization of the difference as "non-business" vs. 
"business-needs-centric" is ... misleading at best.  

Let us speak plainly, and call it what it is: "reasonably secure crypto" 
vs. "crypto weak enough to pass US current export regulations."

Keith

From: Blake Ramsdell <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Alternative symmetric algorithm freely available forIETFS/MIME (re: RC2 licensing).
Date: Thu, 17 Apr 1997 21:04:27 -0700
Sender: [email-masked]

Fair enough -- let me put it this way.  If US domestic restrictions in
this particular case are not part of the IETF standard setting, then how
can we possibly come up with a guaranteed interoperable specification
(which was the primary goal of S/MIME before being introduced to the
IETF, and is still written in the charter that way)?

And I certainly hope that if *your* needs weren't being represented by
the IETF that you would speak up.  It's your duty.

Blake

>-----Original Message-----
>From:	[email-masked] [SMTP:[email-masked]]
>Sent:	Thursday, April 17, 1997 8:42 PM
>To:	Blake Ramsdell
>Cc:	[email-masked]
>Subject:	RE: Alternative symmetric algorithm freely available forIETFS/MIME
>(re: RC2 licensing).
>
>>I'm don't think that Steve is wrong in his wording that "the goals of
>>the IETF are out of step with US companies' business needs".  
>>Consider
>>the following:
>
>The part I have a problem with is "US companies' business needs" - why should
>we care ? What about the needs of New Zealand business, or european or all
>the other hundreds of political entities.
>
>I State:
>	US domestic restrictions should *not* be a par of the IETF standard setting.
>
>
>Yours Sincerely,
>
>
>Lindsay Mathieson
>Black Paw Communications
>
>

From: [email-masked]
Date: Fri, 18 Apr 1997 03:42:22 GMT
CC: [email-masked]
Subject: RE: Alternative symmetric algorithm freely available forIETFS/MIME (re: RC2 licensing).
To: Blake Ramsdell <[email-masked]>
Sender: [email-masked]

>I'm don't think that Steve is wrong in his wording that "the goals of
>the IETF are out of step with US companies' business needs".  
>Consider
>the following:

The part I have a problem with is "US companies' business needs" - why should
we care ? What about the needs of New Zealand business, or european or all
the other hundreds of political entities.

I State:
	US domestic restrictions should *not* be a par of the IETF standard setting.

Yours Sincerely,

Lindsay Mathieson
Black Paw Communications

Date: Thu, 17 Apr 1997 23:38:11 -0400
From: Uri Blumenthal <[email-masked]>
To: [email-masked]
Subject: The RC2 debate
Reply-To: [email-masked]
Sender: [email-masked]

>>>>> "Paul" == Paul E Hoffman <[email-masked]> writes:

    Paul> I'd like to second the motion to split the RC2/40 discussion
    Paul> into two parts. Please note the subject of this part, and
    Paul> reply with this subject if you want to talk about whether or
    Paul> not the S/MIME spec should have a MUST or a SHOULD that
    Paul> includes RC2 encryption.

S/MIME MUST say "MAY include RC2".

NO WAY should it say MUST.

Date: Thu, 17 Apr 1997 20:09:01 -0700
To: [email-masked]
From: Charles Breed <[email-masked]>
Subject: Re: The 40-bit debate
Sender: [email-masked]

I vote that we never force a "MUST" with weak 40-bit crypto, 
Let's not lead the naive to think it's "Secure". 
We all know a brute-force attack against 40-bit
cipher can yield clear text in a short amount of time, so I
believe, we (the IETF community) has a moral obligation to 
the millions of "unsuspecting" users AND we "MUST" have a
spec that protects their content, (as one would think a Secure
Product would...)

Charles Breed

At 07:47 PM 4/17/97 -0700, you wrote:
>I'd like to second the motion to split the RC2/40 discussion into two
>parts. Please note the subject of this part, and reply with this subject if
>you want to talk about whether or not the S/MIME spec should have a MUST
>or a SHOULD that includes 40-bit encryption.
>
>--Paul E. Hoffman, Director
>--Internet Mail Consortium
>
>
>
>

Date: Thu, 17 Apr 1997 20:03:56 -0700
To: [email-masked]
From: Charles Breed <[email-masked]>
Subject: Re: The RC2 debate
Sender: [email-masked]

I vote that RC2 (all key lengths) Should definitely have OIDs, and should
be allowed as a viable profile, but not a "MUST".

Charles Breed

At 07:48 PM 4/17/97 -0700, you wrote:
>I'd like to second the motion to split the RC2/40 discussion into two
>parts. Please note the subject of this part, and reply with this subject if
>you want to talk about whether or not the S/MIME spec should have a MUST
>or a SHOULD that includes RC2 encryption.
>
>--Paul E. Hoffman, Director
>--Internet Mail Consortium
>
>
>
>

Date: Thu, 17 Apr 1997 19:57:38 -0700
To: [email-masked]
From: Charles Breed <[email-masked]>
Subject: RE: S/MIME Charter suggestions...
Sender: [email-masked]

Easy, use a strong "MUST" profile. I think you meant to ask,
"How do us poor US companies export our products"

cb

At 07:17 PM 4/17/97 -0700, you wrote:
>OK, Charles, I'll bite.  How are we going to have strong cryptography
>that interoperates globally?
>
>Blake
>
>>-----Original Message-----
>>From:	Charles Breed [SMTP:[email-masked]]
>>Sent:	Thursday, April 17, 1997 12:36 PM
>>To:	[email-masked]
>>Subject:	S/MIME Charter suggestions...
>>
>>After reading our Chairman, Paul Hoffman's (of IMC) S/MIME definition, 
>>I propose a few, slight modifications...
>>
>>
>>IETF S/MIME Charter
>>-------------------
>>Electronic messaging is rapidly replacing traditional forms
>>of communications for individuals and businesses.  As digital
>>communication techniques accelerate in popularity, so does 
>>the need for data privacy, message integrity, and 
>>non-repudiation of origin.  
>>
>>The IETF S/MIME Working Group is chartered with defining a 
>>standard method to send and receive secure MIME messages 
>>that interoperate globally.  The group will place particular 
>>emphasis on the need for strong cryptography based on open and
>>publicly available algorithms.  In fulfillment of this charter, 
>>the IETF S/MIME Working Group will define the use of file formats, 
>>communications protocols, cryptographic algorithms, digital 
>>certificates and other relevant operational concerns. 
>>
>>================
>>fyi, the currently posted 'charter' for your comparisons...
>>
>>   Description of the Working Group:
>>
>>   S/MIME is a method for encrypting and/or authenticating MIME data.
>>   S/MIME defines a format for the MIME data, the algorithms that must be
>>   used for interoperability, and the additional operational concerns
>>   such as certificates and transport over the Internet.
>>================
>>
>>regards,
>>Charles Breed
>>
>
>

Date: Thu, 17 Apr 1997 19:54:36 -0700
To: [email-masked]
From: Charles Breed <[email-masked]>
Subject: RE: US/MIME
Sender: [email-masked]

All I'm suggesting is that we clearly differentiate
between what is strong and what is not, or S/MIME
might make CNN Headline news, (not good for our industry)

  Joe says, "hey, ya use'g that S/MIME stuff"
  Mike says, "you bet, send me your companies records"
  Joe says, "sure thing, they're on their way"

:-)

At 07:11 PM 4/17/97 -0700, you wrote:
>To further this, I propose the following:
>
>SSSL (Semi-Secure-Sockets-Layer) for implementations that can only
>implement 40-bit RC2 / RC4.  This, of course, would be in TLSS
>(Transport-Level-Semi-Security) also.  We can work on the acronyms.
>These are in use in all of the exportable web servers / browsers from
>Netscape and Microsoft.
>
>Just to be consistent.
>
>Blake
>
>>-----Original Message-----
>>From:	Charles Breed [SMTP:[email-masked]]
>>Sent:	Thursday, April 17, 1997 12:21 PM
>>To:	[email-masked]
>>Subject:	US/MIME
>>
>>
>>If we're all hell-bent on an international interoperable
>>"MUST" profile for S/MIME, Let's not lead the naive to think
>>it's "Secure". We all know a brute-force attack against 40-bit
>>cipher can yield clear text in a short amount of time, so I
>>believe, we (the IETF community) has a moral obligation to inform 
>>the millions of "unsuspecting" users as to the vulnerability of the 
>>proposed specification.
>>
>>Proposal:
>>---------
>>
>>US/MIME, this spec has ONLY one profile, RSA, RC2-40, SHA-1 and 
>>it will be known as the un-secure or US export spec. (or maybe
>>SS/MIME, semi-secure/MIME)
>>
>>S/MIME+ will have a strong "MUST" profile, RSA Public Key with
>>a minimum 1792 bit to match a symmetric cipher (3DES, CAST) of
>>112 bits with SHA-1. This "MUST" profile allows international
>>interoperability as well, it just limits US companies to export.
>>S/MIME will continue to have other profiles using the defined OIDs. 
>>
>>(Yup, it's US export controlled, but ya better take that up with 
>>the US Department of Commerce, Not the IETF)
>>
>>
>>regards,
>>Charles Breed
>
>

Date: Thu, 17 Apr 1997 19:48:23 -0700
To: [email-masked]
From: "Paul E. Hoffman" <[email-masked]>
Subject: The RC2 debate
Sender: [email-masked]

I'd like to second the motion to split the RC2/40 discussion into two
parts. Please note the subject of this part, and reply with this subject if
you want to talk about whether or not the S/MIME spec should have a MUST
or a SHOULD that includes RC2 encryption.

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

Date: Thu, 17 Apr 1997 19:46:07 -0700
To: [email-masked]
From: "Paul E. Hoffman" <[email-masked]>
Subject: RE: Alternative symmetric algorithm freely available forIETFS/MIME (re: RC2 licensing).
Sender: [email-masked]

At 6:56 PM -0700 4/17/97, Blake Ramsdell wrote:
>Consider
>the following:
>
>1. US companies need to sell products outside the US and Canada

Let's be a bit more specific here. *Some* US companies need to sell
products outside the US and Canada (and Mexico, by the way...). Not all of
them. The ones you are talking about are companies that create mail client
software. They are a teeny minority of US companies.

>2. The current discussion about removing RC2 40-bit is about removing
>the necessary component from the specification that would allow this

Not necessarily true. Some people would like to remove RC2/40 altogether,
others would prefer to move it to SHOULD or possibly just a list known,
widely-deployed algorithms. I hear no consensus yet, which isn't surprising
given the topic.

>In any case, this is the business need, and it appears that the IETF
>wants to head the spec in a different direction.

Wrong and wrong.

- It is a business need *for a teeny number of companies*. The vast
majority of US/Canada/Mexico companies have a business need for reliable,
interoperable, secure email. If the IETF can get that with RC2/40, great.
If not, the IETF must listen to the needs of all businesses and still come
up with a spec for reliable, interoperable, secure email.

- "The IETF" doesn't speak with one voice, and thinking that a handful of
comments on one mailing list over two days reflects the voice of the IETF
is just plain silly. The debate is only begun, and not very well I might
add.

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

Date: Thu, 17 Apr 1997 19:47:55 -0700
To: [email-masked]
From: "Paul E. Hoffman" <[email-masked]>
Subject: The 40-bit debate
Sender: [email-masked]

I'd like to second the motion to split the RC2/40 discussion into two
parts. Please note the subject of this part, and reply with this subject if
you want to talk about whether or not the S/MIME spec should have a MUST
or a SHOULD that includes 40-bit encryption.

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

To: [email-masked]
Subject: Re: Alternative symmetric algorithm freely available for IETFS/MIME (re: RC2 licensing). 
Date: Fri, 18 Apr 1997 12:29:18 +1000
From: Scott Merrilees <[email-masked]>
Sender: [email-masked]

>someone wrote:
>>If there is agreement, then I
>>will stand by my earlier conviction;  the goals of the IETF are out of
>>step with US companies' business needs.

Maybe: "The US Government is out of step with US companies' business needs."

Sm

From: Blake Ramsdell <[email-masked]>
To: "'Charles Breed'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: S/MIME Charter suggestions...
Date: Thu, 17 Apr 1997 19:17:03 -0700
Sender: [email-masked]

OK, Charles, I'll bite.  How are we going to have strong cryptography
that interoperates globally?

Blake

>-----Original Message-----
>From:	Charles Breed [SMTP:[email-masked]]
>Sent:	Thursday, April 17, 1997 12:36 PM
>To:	[email-masked]
>Subject:	S/MIME Charter suggestions...
>
>After reading our Chairman, Paul Hoffman's (of IMC) S/MIME definition, 
>I propose a few, slight modifications...
>
>
>IETF S/MIME Charter
>-------------------
>Electronic messaging is rapidly replacing traditional forms
>of communications for individuals and businesses.  As digital
>communication techniques accelerate in popularity, so does 
>the need for data privacy, message integrity, and 
>non-repudiation of origin.  
>
>The IETF S/MIME Working Group is chartered with defining a 
>standard method to send and receive secure MIME messages 
>that interoperate globally.  The group will place particular 
>emphasis on the need for strong cryptography based on open and
>publicly available algorithms.  In fulfillment of this charter, 
>the IETF S/MIME Working Group will define the use of file formats, 
>communications protocols, cryptographic algorithms, digital 
>certificates and other relevant operational concerns. 
>
>================
>fyi, the currently posted 'charter' for your comparisons...
>
>   Description of the Working Group:
>
>   S/MIME is a method for encrypting and/or authenticating MIME data.
>   S/MIME defines a format for the MIME data, the algorithms that must be
>   used for interoperability, and the additional operational concerns
>   such as certificates and transport over the Internet.
>================
>
>regards,
>Charles Breed
>

Date: Thu, 17 Apr 1997 18:56:21 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: RE: Alternative symmetric algorithm freely available for IETF S/MIME).
To: "'SMIME Dev List'" <[email-masked]>, "'SMIME IETF'" <[email-masked]>
Sender: [email-masked]

Folks, while it has been very interesting and I've learned some new stuff, I'm
afraid the discussion of whether or not the licensing terms for RC2 and it's
brethren are adequate is what is moot here. The simple fact of the matter is
that as the owner of the intellectual property in question, RSA has five and
only five options to chose from:

(1) Drop any trade secret claims for the algorithms used in S/MIME.
(2) Completely remove them from the S/MIME standard-to-be. It isn't a question
    of whether or not it can be required -- in point of fact you cannot mention
    these algorithms at all.
(3) Abandon the effort to get S/MIME blessed as an Internet standard.
(4) Get the IETF to treat this as an exception to the current rules concerning
    intellectual property in Internet standards (very unlikely).
(5) Get the IETF to change the current rules concerning intellectual property
    in Internet standards (also very unlikely).

To see why this is so, I cite section 10.2 of RFC2026, which is the document
describing the requirements of the current Internet Standards Process:

  10.2  Confidentiality Obligations

     No contribution that is subject to any requirement of confidentiality
     or any restriction on its dissemination may be considered in any part
     of the Internet Standards Process, and there must be no assumption of
     any confidentiality obligation with respect to any such contribution.

Now, it is my understanding that in order to maintain something's trade secret
status the owner of that trade secret must keep it confidential and cannot
under any circumstances whatsoever agree to its publication. (I'm confident
that I can find citations to back up this point if necessary -- unfortunately
someone has "borrowed" my patent and trade secret textbook so I cannot do so
right now.) If so, this is in direct contradction to the IETF's requirement
that material with confidentially emcumberances cannot be used in any part of
the Internet Standards Process.

In addition, please note that this requirement happens to be one which is
unusually clear, unambiguous, and ineluctable -- there are no weasel-words
about "only if there's no unencumbered alternative" or "must have reasonable
licensing terms", etc. And for my part I think the absence of such words in
this case is entirely defensible: Please recall that the standards process
contains mandatory review steps, and I find it unacceptable for the review
process to involve a need to sign a nondisclosure agreement and quite possibly
pay $$$. As such, I will actively oppose any attempts to either change the
rules or make an exception in this case.

FWIW, I ran this message by the apps area directorate list prior to posting it
here. I only received two comments, one from each of the apps area directors.
Specifically, Keith Moore replied and said he agrees with my analysis. Harald
Alvestrand also replied and says that while he doesn't see a problem with
having a simple reference pointing to RC2 and its OID in the document, what is
there now is clearly unacceptable. So that's the word from two of the ADs who
will have to approve this document before it can enter the IETF standards
track.

				Ned

From: Blake Ramsdell <[email-masked]>
To: "'Charles Breed'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: US/MIME
Date: Thu, 17 Apr 1997 19:11:50 -0700
Sender: [email-masked]

To further this, I propose the following:

SSSL (Semi-Secure-Sockets-Layer) for implementations that can only
implement 40-bit RC2 / RC4.  This, of course, would be in TLSS
(Transport-Level-Semi-Security) also.  We can work on the acronyms.
These are in use in all of the exportable web servers / browsers from
Netscape and Microsoft.

Just to be consistent.

Blake

>-----Original Message-----
>From:	Charles Breed [SMTP:[email-masked]]
>Sent:	Thursday, April 17, 1997 12:21 PM
>To:	[email-masked]
>Subject:	US/MIME
>
>
>If we're all hell-bent on an international interoperable
>"MUST" profile for S/MIME, Let's not lead the naive to think
>it's "Secure". We all know a brute-force attack against 40-bit
>cipher can yield clear text in a short amount of time, so I
>believe, we (the IETF community) has a moral obligation to inform 
>the millions of "unsuspecting" users as to the vulnerability of the 
>proposed specification.
>
>Proposal:
>---------
>
>US/MIME, this spec has ONLY one profile, RSA, RC2-40, SHA-1 and 
>it will be known as the un-secure or US export spec. (or maybe
>SS/MIME, semi-secure/MIME)
>
>S/MIME+ will have a strong "MUST" profile, RSA Public Key with
>a minimum 1792 bit to match a symmetric cipher (3DES, CAST) of
>112 bits with SHA-1. This "MUST" profile allows international
>interoperability as well, it just limits US companies to export.
>S/MIME will continue to have other profiles using the defined OIDs. 
>
>(Yup, it's US export controlled, but ya better take that up with 
>the US Department of Commerce, Not the IETF)
>
>
>regards,
>Charles Breed

From: Blake Ramsdell <[email-masked]>
To: "'Paul E. Hoffman'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Alternative symmetric algorithm freely available forIETFS/MIME (re: RC2 licensing).
Date: Thu, 17 Apr 1997 18:56:26 -0700
Sender: [email-masked]

I'm don't think that Steve is wrong in his wording that "the goals of
the IETF are out of step with US companies' business needs".  Consider
the following:

1. US companies need to sell products outside the US and Canada
2. The current discussion about removing RC2 40-bit is about removing
the necessary component from the specification that would allow this

I don't know how more accurate his statement could be.

And it's not just "expedited" export of a product that is afforded by
having RC2 40-bit -- if you use anything else and you get approval, it
is contingent on providing information about each of the customers you
have sold the product to.  This is, in short, enough paperwork to negate
the effort, especially if you have any kind of distribution channel,
bundling, or any other non-direct sales where end-user accountability is
not possible.

This policy may have changed, and if any evidence of this is presented
through my other email thread we can discuss the possible replacement of
RC2 40-bit.  In that thread, I asked if there was any algorithm that met
the US export requirements and was not an insurmountable administrative
burden to sell as an S/MIME product.  We'll see if anything comes up.

In any case, this is the business need, and it appears that the IETF
wants to head the spec in a different direction.  That's why Steve (and
I) believe that it is out of step.

Blake

>-----Original Message-----
>From:	Paul E. Hoffman [SMTP:[email-masked]]
>Sent:	Thursday, April 17, 1997 4:18 PM
>To:	[email-masked]
>Subject:	RE: Alternative symmetric algorithm freely available forIETFS/MIME
>(re: RC2 licensing).
>
>At 3:45 PM -0700 4/17/97, Steve Dusse wrote:
>>If there is agreement, then I
>>will stand by my earlier conviction;  the goals of the IETF are out of
>>step with US companies' business needs.
>
>I disagree strongly with your wording. There is no "need" for expidited
>export of a product; there is a strong desire. To be more specific, there
>is a strong desire for a small number of companies (mail client
>manufacturers) for expeditied export.
>
>There is a strong need for strong cryptography in all US companies for
>their messaging. This is why RSA included tripleDES in the original S/MIME
>spec. Thus, the goals of the IETF are exactly step with US companies'
>business needs, with the exception of a few companies.
>
>>As such, we should find a way
>>to separate the non-business protocol portions of the S/MIME spec from
>>the US business-needs-centric profiling information.
>
>Again, I disagree with your wording. In my mind, a better way to say this
>is "we need a spec that meets US companies' business needs, and we need to
>also at least acknowledge the strong desires of US mail client vendors."
>
>Further, I'd like to point out to the group as a whole that just because
>other countries don't have export controls today, they might tomorrow. The
>lame ideas of the US government are often imported gleefully by other
>governments. Thus, the 40-bit crypto problem is temporarily US-only. It
>could go away in the US, it could appear in other major software-exporting
>countries, or both.
>
>--Paul E. Hoffman, Director
>--Internet Mail Consortium
>
>

Date: Thu, 17 Apr 1997 18:55:11 -0700
To: [email-masked]
From: Charles Breed <[email-masked]>
Subject: RE: Alternative symmetric algorithm freely available for IETF S/MIME (re: RC2 licensing).
Sender: [email-masked]

There are two separate issues here:

1. Proprietary nature of the algorithm

	and

2. Key length of 40 bit

One argument says, 'No RC2 at any length' key because it's owned by someone
charging some type of royalty. Don't care if it's 128 bit RC2, it's still RC2.

The other argument is, 'Don't want no weak crypto'. Don't care if you're
talking CAST@40, DES@40, RC2@40 or ROT13. This is the 'US export' problem.

The answer is simple, Let's have strong open algorithms !

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

At 04:18 PM 4/17/97 -0700, you wrote:
>At 3:45 PM -0700 4/17/97, Steve Dusse wrote:
>>If there is agreement, then I
>>will stand by my earlier conviction;  the goals of the IETF are out of
>>step with US companies' business needs.
>
>I disagree strongly with your wording. There is no "need" for expidited
>export of a product; there is a strong desire. To be more specific, there
>is a strong desire for a small number of companies (mail client
>manufacturers) for expeditied export.
>
>There is a strong need for strong cryptography in all US companies for
>their messaging. This is why RSA included tripleDES in the original S/MIME
>spec. Thus, the goals of the IETF are exactly step with US companies'
>business needs, with the exception of a few companies.
>
>>As such, we should find a way
>>to separate the non-business protocol portions of the S/MIME spec from
>>the US business-needs-centric profiling information.
>
>Again, I disagree with your wording. In my mind, a better way to say this
>is "we need a spec that meets US companies' business needs, and we need to
>also at least acknowledge the strong desires of US mail client vendors."
>
>Further, I'd like to point out to the group as a whole that just because
>other countries don't have export controls today, they might tomorrow. The
>lame ideas of the US government are often imported gleefully by other
>governments. Thus, the 40-bit crypto problem is temporarily US-only. It
>could go away in the US, it could appear in other major software-exporting
>countries, or both.
>
>--Paul E. Hoffman, Director
>--Internet Mail Consortium
>
>
>
>

Date: Thu, 17 Apr 1997 20:10:23 -0400
From: Uri Blumenthal <[email-masked]>
To: Blake Ramsdell <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Other exportable 40-bit algorithms
Reply-To: [email-masked]
Sender: [email-masked]

>>>>> "Blake" == Blake Ramsdell <[email-masked]> writes:

    Blake> Is there any alternative to RC2 40-bit that meets US export
    Blake> requirements for symmetric algorithms, and does not require
    Blake> you to:

    Blake> 1. Wait an eternity for export approval 2. Register every
    Blake> sale of a product to a non-US/Canada company/individual
    Blake> with the government 3. Require you to implement escrow
    Blake> features in your product

Yes, of course. But you realize, that it's 99.9% unlikely that
you'll be allowed to export the source code, right?

    Blake> RC2 40-bit enjoys both an expedited export approval (I seem
    Blake> to remember ours being a month) and does not have the
    Blake> burden of reporting individual unit sales with the
    Blake> government.  Is this true of CAST 40-bit or DES-40?

No idea about CAST, probably it's too good for it. 

Yes for CDMF (IBM-patented, clever reducing the key strength
	to 40 bits, as opposite to simply accepting a 40-bit
	key only from a user).

Yes for RC4 (legal status unknown to me. The last I heard,
	RSADSI believes it's their property and would
	like you to pay for the license).

Yes for RC2 (same as RC4).

There is no "DES-40" per se, unless you mean CDMF; to the best
of my knowledge.

I'm not aware of any other crypto-algorithm that has expedited
export approval  (which doesn't guarantee you'll be allowed to
export - simply that "Yes" or "No" will be given  within three
weeks or so).

Regards,
Uri     
-=-=-==-=-=-		[email-masked]
<Disclaimer>

From: Blake Ramsdell <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Other exportable 40-bit algorithms
Date: Thu, 17 Apr 1997 16:17:12 -0700
Sender: [email-masked]

Is there any alternative to RC2 40-bit that meets US export requirements
for symmetric algorithms, and does not require you to:

1. Wait an eternity for export approval
2. Register every sale of a product to a non-US/Canada
company/individual with the government
3. Require you to implement escrow features in your product

RC2 40-bit enjoys both an expedited export approval (I seem to remember
ours being a month) and does not have the burden of reporting individual
unit sales with the government.  Is this true of CAST 40-bit or DES-40?

Blake

Date: Thu, 17 Apr 1997 16:18:10 -0700
To: [email-masked]
From: "Paul E. Hoffman" <[email-masked]>
Subject: RE: Alternative symmetric algorithm freely available for IETFS/MIME (re: RC2 licensing).
Sender: [email-masked]

At 3:45 PM -0700 4/17/97, Steve Dusse wrote:
>If there is agreement, then I
>will stand by my earlier conviction;  the goals of the IETF are out of
>step with US companies' business needs.

I disagree strongly with your wording. There is no "need" for expidited
export of a product; there is a strong desire. To be more specific, there
is a strong desire for a small number of companies (mail client
manufacturers) for expeditied export.

There is a strong need for strong cryptography in all US companies for
their messaging. This is why RSA included tripleDES in the original S/MIME
spec. Thus, the goals of the IETF are exactly step with US companies'
business needs, with the exception of a few companies.

>As such, we should find a way
>to separate the non-business protocol portions of the S/MIME spec from
>the US business-needs-centric profiling information.

Again, I disagree with your wording. In my mind, a better way to say this
is "we need a spec that meets US companies' business needs, and we need to
also at least acknowledge the strong desires of US mail client vendors."

Further, I'd like to point out to the group as a whole that just because
other countries don't have export controls today, they might tomorrow. The
lame ideas of the US government are often imported gleefully by other
governments. Thus, the 40-bit crypto problem is temporarily US-only. It
could go away in the US, it could appear in other major software-exporting
countries, or both.

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

From: [email-masked]
Date: Thu, 17 Apr 1997 22:43:16 GMT
CC: [email-masked]
Subject: Re: Alternative symmetric algorithm freely available for IETFS/MIME  (re: RC2 licensing).
To: Keith Moore <[email-masked]>
Sender: [email-masked]

>US export regs are irrelevant unless they somehow prevent a candidate
>algorithm from being made widely available under such terms.

Amen - the US domestic scene appears to have *far* to much influence on the
current spec
--
Lindsay Mathieson
Black Paw Communications
	http://www.blackpaw.com/

From: Steve Dusse <[email-masked]>
To: "'Keith Moore'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Alternative symmetric algorithm freely available for IETFS/MIME (re: RC2 licensing).
Date: Thu, 17 Apr 1997 15:45:02 -0700
Sender: [email-masked]

Keith makes this point rather succintly.  If there is agreement, then I
will stand by my earlier conviction;  the goals of the IETF are out of
step with US companies' business needs.  As such, we should find a way
to separate the non-business protocol portions of the S/MIME spec from
the US business-needs-centric profiling information.

Cheers,
Steve

>----------
>From: 	Keith Moore[SMTP:[email-masked]]
>Sent: 	Thursday, April 17, 1997 2:57 PM
>To: 	Steve Dusse
>Cc: 	[email-masked]; [email-masked]
>Subject: 	Re: Alternative symmetric algorithm freely available for IETFS/MIME
>(re: RC2 licensing).
>
>> If DES is a MUST then US software companies will have a difficult time
>> exporting S/MIME-compliant products.
>
>That's for US companies to discuss with Uncle Sam.  It's not something
>that IETF should concern itself with.
>
>IETF should concern itself with the quality of the algorithm --
>whether it's believed to be of sufficient strength -- and whether it
>is available under fair and nondiscriminatory terms.
>
>US export regs are irrelevant unless they somehow prevent a candidate
>algorithm from being made widely available under such terms.
>
>Keith
>
>
>

From: Keith Moore <[email-masked]>
To: Steve Dusse <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Alternative symmetric algorithm freely available for IETFS/MIME  (re: RC2 licensing).
Date: Thu, 17 Apr 1997 17:57:01 -0400
Sender: [email-masked]

> If DES is a MUST then US software companies will have a difficult time
> exporting S/MIME-compliant products.

That's for US companies to discuss with Uncle Sam.  It's not something
that IETF should concern itself with.

IETF should concern itself with the quality of the algorithm --
whether it's believed to be of sufficient strength -- and whether it
is available under fair and nondiscriminatory terms.

US export regs are irrelevant unless they somehow prevent a candidate
algorithm from being made widely available under such terms.

Keith

Reply-To: [email-masked]
Date: Thu, 17 Apr 1997 17:21:42 -0400
To: [email-masked]
From: Robert Moskowitz <[email-masked]>
Subject: Re: Alternative symmetric algorithm freely available for IETF S/MIME (re: RC2 licensing).
Cc: [email-masked]
Sender: [email-masked]

At 05:14 PM 4/17/97 -0400, [email-masked] wrote:
>>THIS HAS NOTHING TO DO WITH EXPORT!!! Rather what you can use to 
>>'talk' to the government
>
>OK, sorry I misunderstood you there.
>
>But then - is what you can use to 'talk' to the US government (mainly a US
>domestic issue) of concern for the standard ?
>
In part no.  But in so many other IETF standards, DES is a must implement.
This is the case with IPsec.  It is chosen as a MUST implement, because it
is available worldwide without licensing encumberences, I think.

I also would suspect to see DES in other govs requirements, as many model
theirs after FIPS.

To  make RCn a requirement and DES an option is a major shift in IETF work.
 RC2 and RC4 are trade secrets.  RC5 is published, but licensed, I think.

This is much of my concern...

Robert Moskowitz
Chrysler Corporation
(810) 758-8212

From: [email-masked]
Date: Thu, 17 Apr 1997 17:14:03 -0400 (EDT)
CC: [email-masked]
Subject: Re: Alternative symmetric algorithm freely available for IETF S/MIME (re: RC2 licensing).
To: [email-masked]
Sender: [email-masked]

>THIS HAS NOTHING TO DO WITH EXPORT!!! Rather what you can use to 
>'talk' to the government

OK, sorry I misunderstood you there.

But then - is what you can use to 'talk' to the US government (mainly a US
domestic issue) of concern for the standard ?

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

Reply-To: [email-masked]
Date: Thu, 17 Apr 1997 16:09:06 -0400
To: Steve Dusse <[email-masked]>, "'SMIME IETF'" <[email-masked]>
From: Robert Moskowitz <[email-masked]>
Subject: RE: Alternative symmetric algorithm freely available for IETFS/MIME (re: RC2 licensing).
Sender: [email-masked]

At 09:01 AM 4/17/97 -0700, Steve Dusse wrote:
>If DES is a MUST then US software companies will have a difficult time
>exporting S/MIME-compliant products.

Well you can always just give those government workers what they ask for,
40 bit DES :)   I never ment to imply that we can't play mind games too.

Unless there is something about S/MIME that I missed, but a key escrow of
the encrypting certificate would meet the gov's brain-dead key recovery
requirement.  An S/MIME vendor could present an implementation that shows
key recovery working through a CA's key escrow and get out that way.  Nah,
that would be too easy...  Afterall, there is no reason for me to use key
escrow (actually not in this case), so it is not the S/MIME implementors
fault that i do not provide the key recovery.

WAIT A SECOND!  Is there a red herring lurking here?  How could a vendor
get an export license when DES is not a MUST.  That must mean that the
current MUST crypto is weak enough that it passes the 40 bit export rule.
Hmmm.

>
>-steve
>
>>----------
>>From: 	Robert Moskowitz[SMTP:[email-masked]]
>>Sent: 	Wednesday, April 16, 1997 6:20 PM
>>To: 	Peter Whittaker; 'SMIME Dev List'; 'SMIME IETF'
>>Subject: 	Re: Alternative symmetric algorithm freely available for
IETFS/MIME
>>(re: RC2 licensing).
>>
>>At 11:10 AM 4/16/97 -0400, Peter Whittaker wrote:
>>>It has been suggested that the IETF consider specifying an alternative
>>>"MUST" symmetric encryption algorithm in its version of S/MIME.  One of
>>>the alternatives is CAST. Entrust Technologies announced in January that
>>>it was making CAST available.  From the press release:
>>>
>>I was at US Customs today discussing some issues regarding secure
>>communications between Customs and the 'Big 3'.  It was clear that it would
>>be hard to ge anything through over there that did not support a FIPS
>>algorithm.
>>
>>As I recall, DES was SHOULD.  From what I learned today, I'd say that DES
>>is MUST.  And when AES is done then, well I'm not so sure of that....
>>
>>
>>Robert Moskowitz
>>Chrysler Corporation
>>(810) 758-8212
>>
>>
>
>
Robert Moskowitz
Chrysler Corporation
(810) 758-8212

Date: Thu, 17 Apr 1997 12:35:30 -0700
To: [email-masked]
From: Charles Breed <[email-masked]>
Subject: S/MIME Charter suggestions...
Sender: [email-masked]

After reading our Chairman, Paul Hoffman's (of IMC) S/MIME definition, 
I propose a few, slight modifications...

IETF S/MIME Charter
-------------------
Electronic messaging is rapidly replacing traditional forms
of communications for individuals and businesses.  As digital
communication techniques accelerate in popularity, so does 
the need for data privacy, message integrity, and 
non-repudiation of origin.  

The IETF S/MIME Working Group is chartered with defining a 
standard method to send and receive secure MIME messages 
that interoperate globally.  The group will place particular 
emphasis on the need for strong cryptography based on open and
publicly available algorithms.  In fulfillment of this charter, 
the IETF S/MIME Working Group will define the use of file formats, 
communications protocols, cryptographic algorithms, digital 
certificates and other relevant operational concerns. 

================
fyi, the currently posted 'charter' for your comparisons...

   Description of the Working Group:

   S/MIME is a method for encrypting and/or authenticating MIME data.
   S/MIME defines a format for the MIME data, the algorithms that must be
   used for interoperability, and the additional operational concerns
   such as certificates and transport over the Internet.
================

regards,
Charles Breed

Date: Thu, 17 Apr 1997 12:20:45 -0700
To: [email-masked]
From: Charles Breed <[email-masked]>
Subject: US/MIME
Sender: [email-masked]

If we're all hell-bent on an international interoperable
"MUST" profile for S/MIME, Let's not lead the naive to think
it's "Secure". We all know a brute-force attack against 40-bit
cipher can yield clear text in a short amount of time, so I
believe, we (the IETF community) has a moral obligation to inform 
the millions of "unsuspecting" users as to the vulnerability of the 
proposed specification.

Proposal:
---------

US/MIME, this spec has ONLY one profile, RSA, RC2-40, SHA-1 and 
it will be known as the un-secure or US export spec. (or maybe
SS/MIME, semi-secure/MIME)

S/MIME+ will have a strong "MUST" profile, RSA Public Key with
a minimum 1792 bit to match a symmetric cipher (3DES, CAST) of
112 bits with SHA-1. This "MUST" profile allows international
interoperability as well, it just limits US companies to export.
S/MIME will continue to have other profiles using the defined OIDs. 

(Yup, it's US export controlled, but ya better take that up with 
the US Department of Commerce, Not the IETF)

regards,
Charles Breed

Date: Thu, 17 Apr 97 14:46:36 EST
From: "David Gaon" <[email-masked]>
To: [email-masked], [email-masked], Laurence Lundblade <[email-masked]>
Subject: Re[2]: Alternative symmetric algorithm freely available for 
Sender: [email-masked]

     There seems to be some distorted logic in negotiations using 40 bit 
     algorithms
     
     1.   We all know 40 bits is not secure enough and can be easily 
     broken, so what is the point of negotiating to a higher level 
     algorithm with security using 40 bits ??!!  might just as well be in 
     the open (not encrypted at all).
     
     2.   If indeed we need to ""securely negotiate"" for an strong 
     algorithm,  then we might as well use the negotiation algorithm itself 
     for our transaction if we believe that algorithm is ""secure"" 
     (meaning strong enough to resist breaking and that gives us confidence 
     in the security)
     
     David Gaon

______________________________ Reply Separator _________________________________
Subject: Re: Alternative symmetric algorithm freely available for IET
Author:  Laurence Lundblade <[email-masked]> at smtp
Date:    4/17/97 12:31 PM

Peter, what's the (US) export status of CAST?  I understand one of the 
reasons RC2 is attractive is that it has been cleared with the US commerce 
department for easy export at 40 bits. RC2's ease of export was cited as 
one of the main reasons for it's use at the IETF BOF.
     
LL
     
At 11:10 AM -0400 4/16/97, Peter Whittaker wrote:
>It has been suggested that the IETF consider specifying an alternative 
>"MUST" symmetric encryption algorithm in its version of S/MIME.  One of 
>the alternatives is CAST. Entrust Technologies announced in January that 
>it was making CAST available.  From the press release:
>
> <stuff deleted>
>
>Peter Whittaker         Entrust Key Validation Sequence:  7ORS-NGND-P6ZX 
>Senior Designer, PKI    mailto:[email-masked]    Phone: +1 613 765 2064 
>Entrust Technologies    http://www.entrust.com      Fax: +1 613 765 3520

     

Date: Thu, 17 Apr 1997 14:55:53 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: RE: Alternative symmetric algorithm freely available for IETFS/MIME (re: RC2 licensing).
Sender: [email-masked]

> >From: 	Robert Moskowitz[SMTP:[email-masked]]
> >
> >As I recall, DES was SHOULD.  From what I learned today, I'd say that DES
> >is MUST.  And when AES is done then, well I'm not so sure of that....
>
> From: Steve Dusse <[email-masked]>
> 
> If DES is a MUST then US software companies will have a difficult time
> exporting S/MIME-compliant products.
> 
> -steve

Why?

Presumably DES-40 should be no more difficult to export than RC2-40
(Lotus does it), and DES-56 should be much easier to export than RC2-128.

Date: Thu, 17 Apr 1997 09:04:05 -0700
To: Peter Whittaker <[email-masked]>, "'SMIME IETF'" 	 <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: Alternative symmetric algorithm freely available for IETF S/MIME (re: RC2 licensing).
Sender: [email-masked]

Peter, what's the (US) export status of CAST?  I understand one of the
reasons RC2 is attractive is that it has been cleared with the US commerce
department for easy export at 40 bits. RC2's ease of export was cited as
one of the main reasons for it's use at the IETF BOF.

LL

At 11:10 AM -0400 4/16/97, Peter Whittaker wrote:
>It has been suggested that the IETF consider specifying an alternative
>"MUST" symmetric encryption algorithm in its version of S/MIME.  One of
>the alternatives is CAST. Entrust Technologies announced in January that
>it was making CAST available.  From the press release:
>
> <stuff deleted>
>
>Peter Whittaker         Entrust Key Validation Sequence:  7ORS-NGND-P6ZX
>Senior Designer, PKI    mailto:[email-masked]    Phone: +1 613 765 2064
>Entrust Technologies    http://www.entrust.com      Fax: +1 613 765 3520

From: Steve Dusse <[email-masked]>
To: "'SMIME IETF'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Alternative symmetric algorithm freely available for IETFS/MIME (re: RC2 licensing).
Date: Thu, 17 Apr 1997 09:01:42 -0700
Sender: [email-masked]

If DES is a MUST then US software companies will have a difficult time
exporting S/MIME-compliant products.

-steve

>----------
>From: 	Robert Moskowitz[SMTP:[email-masked]]
>Sent: 	Wednesday, April 16, 1997 6:20 PM
>To: 	Peter Whittaker; 'SMIME Dev List'; 'SMIME IETF'
>Subject: 	Re: Alternative symmetric algorithm freely available for IETFS/MIME
>(re: RC2 licensing).
>
>At 11:10 AM 4/16/97 -0400, Peter Whittaker wrote:
>>It has been suggested that the IETF consider specifying an alternative
>>"MUST" symmetric encryption algorithm in its version of S/MIME.  One of
>>the alternatives is CAST. Entrust Technologies announced in January that
>>it was making CAST available.  From the press release:
>>
>I was at US Customs today discussing some issues regarding secure
>communications between Customs and the 'Big 3'.  It was clear that it would
>be hard to ge anything through over there that did not support a FIPS
>algorithm.
>
>As I recall, DES was SHOULD.  From what I learned today, I'd say that DES
>is MUST.  And when AES is done then, well I'm not so sure of that....
>
>
>Robert Moskowitz
>Chrysler Corporation
>(810) 758-8212
>
>

Reply-To: [email-masked]
Date: Thu, 17 Apr 1997 10:20:42 -0400
To: [email-masked]
From: Robert Moskowitz <[email-masked]>
Subject: Re: Alternative symmetric algorithm freely available for IETF S/MIME (re: RC2 licensing).
Cc: [email-masked]
Sender: [email-masked]

At 10:57 AM 4/17/97 GMT, [email-masked] wrote:
>>I was at US Customs today discussing some issues regarding secure
>>communications between Customs and the 'Big 3'.  It was clear that it 
>>would
>>be hard to ge anything through over there that did not support a FIPS
>>algorithm.
>
>Should the IETF be concerned with the us customs export restrictions ? I know
>I'm not. I don't think domestic US restrictions should be an issue in an
>international spec, and I'm sure the (large) international developer
>community feels the same.

THIS HAS NOTHING TO DO WITH EXPORT!!! Rather what you can use to 'talk' to
the government.  Forget about things like key recovery fights.  That is
peanuts and noise.  This is basics and is actually easy to meet.

>Perhaps the IETF should just set a algorithm and key size minimum required
>for implementing a "secure" transaction, and leave concerns with export
>restrictions upto those effected - i.e. people in the US, not everybody else
>in the world.
>
>
>--
>Lindsay Mathieson
>Black Paw Communications
>	Using MailCat Beta for Win32 Beta Vs 2.0.0.3, on April 17, 1997, in Win95
>4.0
>Checkout the latest (and greatest <G>) mail client, MailCat at:
>	http://www.powerup.com.au/~lindsay
>
>
>
>
Robert Moskowitz
Chrysler Corporation
(810) 758-8212

From: [email-masked]
CC: [email-masked]
Date: 17 Apr 1997 10:57:58 GMT
Subject: Re: Alternative symmetric algorithm freely available for IETF S/MIME (re: RC2 licensing).
To: [email-masked]
Sender: [email-masked]

>I was at US Customs today discussing some issues regarding secure
>communications between Customs and the 'Big 3'.  It was clear that it 
>would
>be hard to ge anything through over there that did not support a FIPS
>algorithm.

Should the IETF be concerned with the us customs export restrictions ? I know
I'm not. I don't think domestic US restrictions should be an issue in an
international spec, and I'm sure the (large) international developer
community feels the same.

Perhaps the IETF should just set a algorithm and key size minimum required
for implementing a "secure" transaction, and leave concerns with export
restrictions upto those effected - i.e. people in the US, not everybody else
in the world.

--
Lindsay Mathieson
Black Paw Communications
	Using MailCat Beta for Win32 Beta Vs 2.0.0.3, on April 17, 1997, in Win95
4.0
Checkout the latest (and greatest <G>) mail client, MailCat at:
	http://www.powerup.com.au/~lindsay

Date: Thu, 17 Apr 97 08:19:30 EST
From: "David Gaon" <[email-masked]>
To: [email-masked], Geoff Klein <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re[4]: 2nd S/MIME BOF meeting minutes
Sender: [email-masked]

     >   Mail capability information is better left in your X.500 entry >   
     >(someday!)
     
     >Until then we bable :)

     No we don't bable - WE PLAN for that eventuality and design protocols 
     and certificates that separate that information instead of embedding 
     it.
     
     David Gaon

______________________________ Reply Separator _________________________________
Subject: Re: Re[2]: 2nd S/MIME BOF meeting minutes
Author:  Geoff Klein <[email-masked]> at smtp
Date:    4/16/97 6:28 PM

-----BEGIN PGP SIGNED MESSAGE-----
     
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
     
To: [email-masked], [email-masked], [email-masked],
 [email-masked], [email-masked]
Date: Wed Apr 16 23:49:26 1997
     
Bill Wohler,
     
>   More often than certificates would.  I see people using more than 
>   one mail system at the same time as well.
     
Presumably with separate email addresses, identities/credentials and 
certificates ?
     
>   Mail capability information is better left in your X.500 entry 
>   (someday!)
     
Until then we bable :)
     
Geoff.

From: Takeshi Yoneda <[email-masked]>
To: "'SMIME IETF'" <[email-masked]>, "'SMIME Dev List'" <[email-masked]>
Subject: Can DES be MUST algorithm in international use of S/MIME?
Date: Thu, 17 Apr 1997 11:51:16 +0900
Sender: [email-masked]

I think if there is no export limitation about DES, DES is the best candidate for MUST algorithm.
But in actual, DES is not exportable outside US and Canada.

On the other hand,  DES can be implemented outside of US.
 It would be  possible to exchange encrypted messages by DES between US and other countries
by using S/MIME compatible softwares in which DES are implemented in each countries.

What should I  think about such situation?

Takeshi Yoneda

Mitsubishi Electoric Corp.
Info. Tech. R&D Center
Infomation Security Dept.
TEL +81-467-41-2182
FAX +81-467-41-2138
Takeshi Yoneda

Reply-To: [email-masked]
Date: Wed, 16 Apr 1997 21:20:38 -0400
To: Peter Whittaker <[email-masked]>, "'SMIME Dev List'" <[email-masked]>, "'SMIME IETF'" <[email-masked]>
From: Robert Moskowitz <[email-masked]>
Subject: Re: Alternative symmetric algorithm freely available for IETF S/MIME (re: RC2 licensing).
Sender: [email-masked]

At 11:10 AM 4/16/97 -0400, Peter Whittaker wrote:
>It has been suggested that the IETF consider specifying an alternative
>"MUST" symmetric encryption algorithm in its version of S/MIME.  One of
>the alternatives is CAST. Entrust Technologies announced in January that
>it was making CAST available.  From the press release:
>
I was at US Customs today discussing some issues regarding secure
communications between Customs and the 'Big 3'.  It was clear that it would
be hard to ge anything through over there that did not support a FIPS
algorithm.

As I recall, DES was SHOULD.  From what I learned today, I'd say that DES
is MUST.  And when AES is done then, well I'm not so sure of that....

Robert Moskowitz
Chrysler Corporation
(810) 758-8212

From: Peter Whittaker <[email-masked]>
To: "'SMIME Dev List'" <[email-masked]>, "'SMIME IETF'" <[email-masked]>
Subject: Followups in the IETF list (RE: Alternative symmetric algorithm freely available for IETF S/MIME).
Date: Wed, 16 Apr 1997 19:56:32 -0400
Sender: [email-masked]

Given that the subject at hand is what the IETF might do with the
specification it may publish based on S/MIME, it is appropriate to carry
all followup discussions to the IETF mailing list.  I should have noted
this in my original message.

My excuse for posting to both lists is that I felt this might have been
of broader interest.  Nevertheless, followups on what the IETF should do
should be directed to the IETF list only.  To subscribe to the IETF
S/MIME list, send a message to [email-masked] with the word
"subscribe" in the body of the message.

pww

To: Geoff Klein <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Re[2]: 2nd S/MIME BOF meeting minutes
Date: Wed, 16 Apr 1997 14:46:12 -0700
From: Bill Wohler <[email-masked]>
Sender: [email-masked]

Geoff Klein <[email-masked]> writes:
> >   More often than certificates would.  I see people using more than
> >   one mail system at the same time as well.
> 
> Presumably with separate email addresses, identities/credentials and 
> certificates ?

  No, why?  In a given day, I'll use MH (mostly), mailx, exmh, pine,
  ZMail, Eudora, Netscape, etc. and even cat to read my mail depending
  the need and mood.  Why would I need to have a dozen addresses and
  certificates?

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: Geoff Klein <[email-masked]>
Date: Wed Apr 16 23:49:34 1997
To: [email-masked]
Subject: Re: Re[2]: 2nd S/MIME BOF meeting minutes
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

To: [email-masked], [email-masked], [email-masked],
 [email-masked], [email-masked]
Date: Wed Apr 16 23:49:26 1997

Bill Wohler,

>   More often than certificates would.  I see people using more than
>   one mail system at the same time as well.

Presumably with separate email addresses, identities/credentials and 
certificates ?

>   Mail capability information is better left in your X.500 entry 
>   (someday!)

Until then we bable :)

Geoff.

To: Geoff Klein <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Re[2]: 2nd S/MIME BOF meeting minutes
Date: Wed, 16 Apr 1997 10:39:39 -0700
From: Bill Wohler <[email-masked]>
Sender: [email-masked]

Geoff Klein <[email-masked]> writes:
> [email-masked] writes:
> > I think the problem here is if you put information about your mail
> > capabilities in your certificate, then when your mail capabilities
> > change, your certificate changes.
> 
> Sure, but these don't change that often.

  More often than certificates would.  I see people using more than
  one mail system at the same time as well.

  Mail capability information is better left in your X.500 entry (someday!)

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: Geoff Klein <[email-masked]>
Date: Wed Apr 16 19:24:17 1997
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re[2]: 2nd S/MIME BOF meeting minutes
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

To: [email-masked], [email-masked], [email-masked],
 [email-masked], [email-masked]
Date: Wed Apr 16 19:24:09 1997

Blake,

> I think the problem here is if you put information about your mail
> capabilities in your certificate, then when your mail capabilities
> change, your certificate changes.

Sure, but these don't change that often. IMHO it's a small price to pay for   
guaranteed international inter operability that would result from a 
standard method for publishing crypto capabilities.

Geoff.

From: Peter Whittaker <[email-masked]>
To: "'SMIME Dev List'" <[email-masked]>, "'SMIME IETF'" <[email-masked]>
Subject: Alternative symmetric algorithm freely available for IETF S/MIME (re: RC2 licensing).
Date: Wed, 16 Apr 1997 11:10:58 -0400
Sender: [email-masked]

It has been suggested that the IETF consider specifying an alternative
"MUST" symmetric encryption algorithm in its version of S/MIME.  One of
the alternatives is CAST. Entrust Technologies announced in January that
it was making CAST available.  From the press release:

	Entrust® Technologies announced today that it is making a version of
its
	CAST encryption algorithm available for free commercial and
non-commercial
	use.
	...
	CAST is a design procedure for symmetric encryption algorithms.
Following
	the design procedure and choosing appropriate values for various
parameters
	creates an algorithm which is tailored to suit particular needs. As a
result,
	CAST defines a family of encryption algorithms, each of which is
conceptually
	simple, and easily implemented, flexible and very efficient in terms of
	encryption/decryption speed. CAST can be specified as the default in
products
	that require non-proprietary algorithms. 

The full text of the press release is available at
http://www.entrust.com/01_24_97.htm.

The paper documenting the CAST design process can be found in our white
papers library at http://www.entrust.com/library.htm.  Scroll down about
halfway to find the CAST papers.  There are two, be sure to get them
both.

Peter Gutmann of New Zealand posted C code for CAST-128, derived from
the description on the web page, to sci.scrypt a few weeks ago, so it is
globally available now.  Test vectors in the spec allow verification
that the implementation is correct.  My apologies for not having a
reference to his article available.

I've included the abstracts of the design papers:

	"Constructing Symmetric Cyphers Using the CAST Design Procedure"

	Abstract. This paper describes the CAST design procedure for
constructing
	a family of DES-like Substitution-Permutation Network (SPN) ciphers.

	The version of the CAST algorithm discussed in this paper is now
available
	royalty-free for both commercial and non-commercial use - see the
related
	press release for details.

	"CAST Design Procedure Addendum"

	Abstract. This addendum to the CAST paper (above) specifies how to use
	CAST with a variable key size (40 to 128 bits), provides test vectors
for 40-,
	80-, and 128-bit keys (so that implementations can be verified for
	correctness), and includes some AlgorithmIdentifiers (i.e., OBJECT
	IDENTIFIERs with associated Parameters) which have been defined for
CAST.

Both papers are available from the Web page in PDF and in MS RTF.

The first paper is also scheduled to appear in the journal "Designs,
Codes, and Cryptography".

Some of the advantages of CAST are:

	Free for commercial and non-commercial use.

	Variable key sizes:  CAST has been implemented with 40, 64, 80,
	and 128 bit keys.

	Guaranteed resistance to differential and linear cryptanalysis attacks.

	Immunity to weak keys and complementary keys.

Additional information about CAST is available from Queen's University:
http://adonis.ee.queensu.ca:8000/cast/cast.html

pww

Peter Whittaker         Entrust Key Validation Sequence:  7ORS-NGND-P6ZX
Senior Designer, PKI    mailto:[email-masked]    Phone: +1 613 765 2064
Entrust Technologies    http://www.entrust.com      Fax: +1 613 765 3520

Date: Wed, 16 Apr 97 08:23:19 EST
From: "David Gaon" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], Blake Ramsdell <[email-masked]>
Subject: Re[5]: 2nd S/MIME BOF meeting minutes
Sender: [email-masked]

     Why do we need to put all the mail capabilities in the certificate ?
     Why not separate the fact that I have RSA and put that somewhere in 
     the message header for the recipient (and everybody, I do not care) to 
     see ???
     
     David Gaon

______________________________ Reply Separator _________________________________
Subject: RE: RE: Re[2]: 2nd S/MIME BOF meeting minutes
Author:  Blake Ramsdell <[email-masked]> at smtp
Date:    4/16/97 6:42 AM

I think the problem here is if you put information about your mail 
capabilities in your certificate, then when your mail capabilities 
change, your certificate changes.
     
Blake
     
>-----Original Message-----
>From: Geoff Klein [SMTP:[email-masked]] 
>Sent: Tuesday, April 15, 1997 3:45 PM
>To: [email-masked]; [email-masked]; [email-masked] 
>Subject: Re: RE: Re[2]: 2nd S/MIME BOF meeting minutes
>
>-----BEGIN PGP SIGNED MESSAGE-----
>
>Mime-Version: 1.0
>Content-Type: text/plain
>Content-Transfer-Encoding: 7bit
>
>To: [email-masked], [email-masked], [email-masked] 
>Date: Tue Apr 15 22:44:56 1997
>
>
>> In the world of peer-to-peer store-and-forward communications (e.g. 
>> email) there really is no negotiation possible at "start of
>> communications".  This is especially evident in the case of a multicast 
>> message, i.e. sending a message to a bunch of recipients.
>> 
>> In such an environment, negotiation can be done either out of band 
>> beforehand (e.g. by looking up some entries in a directory) or via
>> exchange of email by the end users who are not always savvy enough to 
>> effectively negotiate encryption algorithms and key sizes.  It was our 
>> intent when creating S/MIME to provide some base level of
>> interoperability possible among all S/MIME-enabled user agents (i.e. 
>> the "MUSTS") and an easy path to negotiating the use of the strongest 
>> possible encryption where both ends are capable (i.e. the "SHOULDS"). 
>> 
>> -steve
>
>Since certificates are in any case a prerequisit, supported/prefered 
>algorithms could be published as extended properties of an X509.
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.3i
>Charset: noconv
>
>iQCVAwUBM1PozULv5OMYFK1FAQH6nQP+OQf1E2yJ0JgfRGkLBvbh4zAzTgd23le6 
>FMj4HHQPNV8zHbHFTpby8QVzrb/i4Ufx0IVQpQyKRfeaXrzcF4D3lKuQ/sqfWYUZ 
>miYKo/M64iO8Y8Dgcc5JQmOPiV1U+GlYje39S4iOjJ4yjDr+WODS1kuL6h4FPl2y 
>iM80oZ0XvHE=
>=VD0l
>-----END PGP SIGNATURE-----
>

From: Blake Ramsdell <[email-masked]>
To: "'Geoff Klein'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: RE: Re[2]: 2nd S/MIME BOF meeting minutes
Date: Wed, 16 Apr 1997 03:42:15 -0700
Sender: [email-masked]

I think the problem here is if you put information about your mail
capabilities in your certificate, then when your mail capabilities
change, your certificate changes.

Blake

>-----Original Message-----
>From:	Geoff Klein [SMTP:[email-masked]]
>Sent:	Tuesday, April 15, 1997 3:45 PM
>To:	[email-masked]; [email-masked]; [email-masked]
>Subject:	Re: RE: Re[2]: 2nd S/MIME BOF meeting minutes
>
>-----BEGIN PGP SIGNED MESSAGE-----
>
>Mime-Version: 1.0
>Content-Type: text/plain
>Content-Transfer-Encoding: 7bit
>
>To: [email-masked], [email-masked], [email-masked]
>Date: Tue Apr 15 22:44:56 1997
>
>
>> In the world of peer-to-peer store-and-forward communications (e.g.
>> email) there really is no negotiation possible at "start of
>> communications".  This is especially evident in the case of a multicast
>> message, i.e. sending a message to a bunch of recipients.
>> 
>> In such an environment, negotiation can be done either out of band
>> beforehand (e.g. by looking up some entries in a directory) or via
>> exchange of email by the end users who are not always savvy enough to
>> effectively negotiate encryption algorithms and key sizes.  It was our
>> intent when creating S/MIME to provide some base level of
>> interoperability possible among all S/MIME-enabled user agents (i.e. 
>> the "MUSTS") and an easy path to negotiating the use of the strongest
>> possible encryption where both ends are capable (i.e. the "SHOULDS").
>> 
>> -steve
>
>Since certificates are in any case a prerequisit, supported/prefered 
>algorithms could be published as extended properties of an X509.
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.3i
>Charset: noconv
>
>iQCVAwUBM1PozULv5OMYFK1FAQH6nQP+OQf1E2yJ0JgfRGkLBvbh4zAzTgd23le6
>FMj4HHQPNV8zHbHFTpby8QVzrb/i4Ufx0IVQpQyKRfeaXrzcF4D3lKuQ/sqfWYUZ
>miYKo/M64iO8Y8Dgcc5JQmOPiV1U+GlYje39S4iOjJ4yjDr+WODS1kuL6h4FPl2y
>iM80oZ0XvHE=
>=VD0l
>-----END PGP SIGNATURE-----
>

Date: Wed, 16 Apr 1997 00:03:16 -0400
From: Uri Blumenthal <[email-masked]>
To: [email-masked] (Jeff Smith)
Cc: [email-masked], [email-masked]
Subject: RE: RC2 Licensing
Reply-To: [email-masked]
Sender: [email-masked]

>>>>> "Jeff" == Jeff Smith <[email-masked]> writes:

    Jeff> I would like to know what the licensing fee will be after
                                                              ^^^^^
    Jeff> RC2 has been accepted as a standard compression algorithm
    Jeff> for the S/MIME standard.

NO! "If" - NOT "after"!

I am STRONGLY against making a non-free algorithm part of the
standard. I'm 100% OPPOSED to making it a required standard.

In the world where crypto algorithms are in abundance, it is
unwise to follow a proprietary lock-in road... There is zero
technical justification.

    Jeff> By analogy, although this is not an officially sanctioned
    Jeff> standard, PDF is an open trade mark -- Adobe does not own
    Jeff> it; they only own the mark for Acrobat.  And Adobe changed
    Jeff> the Acrobat PDF format in the 1.2 version to remove any
    Jeff> proprietary compression algorithms.

And there already are free PDF viewers and writers - so PDF has
pretty good chance to conquer the Net.

Regards,                   [To reply, remove "NOSPAM!" from the 
Uri                         "Reply-To:" field]
-=-=-==-=-=-		[email-masked]
<Disclaimer>

Date: Tue, 15 Apr 1997 17:42:13 -0700
To: Laurence Lundblade <[email-masked]>, Steve Dusse <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked], "[email-masked]'"  <[email-masked]>
From: [email-masked] (Jeff Smith)
Subject: RE: RC2 Licensing
Sender: [email-masked]

I would like to know what the licensing fee will be after
RC2 has been accepted as a standard compression algorithm 
for the S/MIME standard.  I fear that vendors such as 
myself would be at a significant risk in this event unless
there were open alternatives as part of the standard.

On a slightly different but equally relevant note,
RSA already has proposed a per unit royalty for use of
their algorithms.  Companies such as Netscape and Microsoft
can afford to buy out a license with lots of cash
or stock.  Companies such as Tumbleweed Software cannot
and hence will have trouble competing, particularly
given some of the new business models in place for
internet distribution.  Importantly, in some respects,
Netscape and Microsoft have incentives to support the
RC2 standard as it acts as a barrier to entry into
the S/MIME market for less capitalized companies.

By analogy, although this is not an officially
sanctioned standard, PDF is an open trade mark --
Adobe does not own it; they only own the mark
for Acrobat.  And Adobe changed the Acrobat PDF 
format in the 1.2 version to remove any proprietary
compression algorithms.  The legacy issues with PDF
1.1 and 1.0 documents due to proprietary compression 
algorithms will be around for some time. And in this
case, the cost of the license to these proprietary
algorithms increased with the proliferation of the
format.

In short, small internet start-up companies are
vulnerable today and will become more vulnerable
tomorrow with the existing proposal for RC2. Of
course the trademark issue is significant as well.

Jeffrey C. Smith
CEO, Tumbleweed Software

At 12:23 PM 4/15/97 -0700, Laurence Lundblade wrote:
>Steve, I know this is a delecate subject, but I'm not at all sure that the
>domestic issue is moot.  There is certainly a community of free and
>share-ware developers that don't have access to RC2 now that would probably
>like to have access to it.  The question is how important is that
>community. There are still large segments of the Internet e-mail community
>that use freeware like Pine. In fact I believe the most UNIX internet
>e-mail is freeware based as there are few commercial products.  This may
>become an issue as folks try to deploy S/MIME.
>
>I'm also not sure that the IETF views this issue as moot. I don't recall
>the discussions at the BOF being qualified as domestic versus
>international. My understanding was that any technology that was encumbered
>indefinitely was a problem.
>
>LL
>
>
>
>At 11:11 AM -0700 4/15/97, Steve Dusse wrote:
>>Hi Walt,
>>
>>RSA's official position on RC2 is that it is a trade secret and that any
>>implementation of RC2 anywhere in the world, other than the copyrighted
>>code in RSA's software toolkits, was derived from RSA's toolkits
>>illegally (e.g. via reverse engineering or otherwise).
>>
>>We are working very hard to come up with a licensing scheme that is
>>acceptable to everyone (an oxymoron of sorts...) for use in S/MIME.
>>Most of the US e-mail vendors have already licensed this technology so
>>the issue domestically is fairly moot.  Internationally, we have a much
>>greater challenge, how to get RC2 technology legally to overseas S/MIME
>>developers in toolkit form.  Not an easy task.  Suggestions are welcome.
>>
>>Cheers,
>>Steve Dusse
>>CTO
>>RSA
>>
>>
>>>----------
>>>From: 	[email-masked][SMTP:[email-masked]]
>>>Sent: 	Tuesday, April 15, 1997 8:13 AM
>>>To: 	[email-masked]
>>>Subject: 	RC2 Licensing
>>>
>>>
>>>Lindsay Mathieson asked the question regarding the licensing issues of
>>>RC2 (or other RSA algorithms) outside of the RSA toolkits (i.e. using
>>>the crypl200 library).  If there was a response, can you please repeat
>>>it.  I seemed to have missed it.
>>>
>>>Thanks,
>>>Walt Boland
>>>
>
>
>
>

From: "Chris Bartram" <[email-masked]>
Organization: 3k Associates
Reply-To: [email-masked]
Date: Tue, 15 Apr 1997 16:51:56 -0400
Subject: Fw: Re[2]: RC2 Licensing
To: [email-masked]
Sender: [email-masked]

--_-+-_-04/15/97 16:51:56-_-+-_
Content-Type: Text/Plain
Content-Disposition: inline

This message has been forwarded to you.

--_-+-_-04/15/97 16:51:56-_-+-_
From: "Chris Bartram" <[email-masked]>
Organization: 3k Associates
Reply-To: [email-masked]
Message-Id: <[email-masked]>
X-Mailer: NetMail/3000 [Version B.06 97/04/09]
MIME-Version: 1.0
Content-Type: Text/Plain
Date: Tue, 15 Apr 1997 16:49:19 -0400
X-Hpdesk-Priority: 3 (Normal Priority)
Subject: Re[2]: RC2 Licensing
To: [email-masked]

 In  [email-masked] writes:

> RSA's official position on RC2 is that it is a trade secret and that any
> implementation of RC2 anywhere in the world, other than the copyrighted
> code in RSA's software toolkits, was derived from RSA's toolkits
> illegally (e.g. via reverse engineering or otherwise).
>
> We are working very hard to come up with a licensing scheme that is
> acceptable to everyone (an oxymoron of sorts...) for use in S/MIME.
> Most of the US e-mail vendors have already licensed this technology so
> the issue domestically is fairly moot.  Internationally, we have a much
> greater challenge, how to get RC2 technology legally to overseas S/MIME
> developers in toolkit form.  Not an easy task.  Suggestions are welcome.

So what about those of us that work on platforms not blessed by RSA? Last I
asked (about HP3000s in particular) RSA's position was that they had no
interest in porting to that platform... and we're not willing to pay $50k(?)
to license source code ourselves to do a port that we'd then have to pay RSA
for the right to use... And we can't "legally" use any "public domain" code...
And just for fun I even asked about paying RSA to port and was told there
weren't resources available to do it even if we (or someone) was willing to
pay to have the toolset(s) ported.

I'm sure there are other platforms that fall into the same boat. I guess that
leaves us stuck with "standards" which we can't legally meet. Wonderful.

                   -Chris Bartram
                    3k Associates, Inc.

--_-+-_-04/15/97 16:51:56-_-+-_--

From: Geoff Klein <[email-masked]>
Date: Tue Apr 15 22:45:02 1997
To: [email-masked], [email-masked], [email-masked]
Subject: Re: RE: Re[2]: 2nd S/MIME BOF meeting minutes
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

To: [email-masked], [email-masked], [email-masked]
Date: Tue Apr 15 22:44:56 1997

> In the world of peer-to-peer store-and-forward communications (e.g.
> email) there really is no negotiation possible at "start of
> communications".  This is especially evident in the case of a multicast
> message, i.e. sending a message to a bunch of recipients.
> 
> In such an environment, negotiation can be done either out of band
> beforehand (e.g. by looking up some entries in a directory) or via
> exchange of email by the end users who are not always savvy enough to
> effectively negotiate encryption algorithms and key sizes.  It was our
> intent when creating S/MIME to provide some base level of
> interoperability possible among all S/MIME-enabled user agents (i.e. 
> the "MUSTS") and an easy path to negotiating the use of the strongest
> possible encryption where both ends are capable (i.e. the "SHOULDS").
> 
> -steve

Since certificates are in any case a prerequisit, supported/prefered 
algorithms could be published as extended properties of an X509.

Date: Tue, 15 Apr 1997 12:23:41 -0700
To: Steve Dusse <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked], "[email-masked]'" 	 <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: RE: RC2 Licensing
Sender: [email-masked]

Steve, I know this is a delecate subject, but I'm not at all sure that the
domestic issue is moot.  There is certainly a community of free and
share-ware developers that don't have access to RC2 now that would probably
like to have access to it.  The question is how important is that
community. There are still large segments of the Internet e-mail community
that use freeware like Pine. In fact I believe the most UNIX internet
e-mail is freeware based as there are few commercial products.  This may
become an issue as folks try to deploy S/MIME.

I'm also not sure that the IETF views this issue as moot. I don't recall
the discussions at the BOF being qualified as domestic versus
international. My understanding was that any technology that was encumbered
indefinitely was a problem.

LL

At 11:11 AM -0700 4/15/97, Steve Dusse wrote:
>Hi Walt,
>
>RSA's official position on RC2 is that it is a trade secret and that any
>implementation of RC2 anywhere in the world, other than the copyrighted
>code in RSA's software toolkits, was derived from RSA's toolkits
>illegally (e.g. via reverse engineering or otherwise).
>
>We are working very hard to come up with a licensing scheme that is
>acceptable to everyone (an oxymoron of sorts...) for use in S/MIME.
>Most of the US e-mail vendors have already licensed this technology so
>the issue domestically is fairly moot.  Internationally, we have a much
>greater challenge, how to get RC2 technology legally to overseas S/MIME
>developers in toolkit form.  Not an easy task.  Suggestions are welcome.
>
>Cheers,
>Steve Dusse
>CTO
>RSA
>
>
>>----------
>>From: 	[email-masked][SMTP:[email-masked]]
>>Sent: 	Tuesday, April 15, 1997 8:13 AM
>>To: 	[email-masked]
>>Subject: 	RC2 Licensing
>>
>>
>>Lindsay Mathieson asked the question regarding the licensing issues of
>>RC2 (or other RSA algorithms) outside of the RSA toolkits (i.e. using
>>the crypl200 library).  If there was a response, can you please repeat
>>it.  I seemed to have missed it.
>>
>>Thanks,
>>Walt Boland
>>

Date: Tue, 15 Apr 97 14:38:24 EST
From: "David Gaon" <[email-masked]>
To: [email-masked], Steve Dusse <[email-masked]>
Subject: Re[4]: 2nd S/MIME BOF meeting minutes
Sender: [email-masked]

     Thank you Steve
     
     You  hit on 2 ways - directory look up and prior e-mail exchange
     
     A 3rd way would be to encrypt using an algorithm and identifying the 
     algorithm to the recipient in the open paret of the message.
     
     Still, if I understand you correctly, you propose to use the ""MUST"" 
     to securely negotiate for an algorithm and key !!
     
     If that be true,  then:
     - why do we need 3 profiles in the spec, surely one would be 
     sufficient
     - if the profile for negotiation is strong enough, 
          -- then why not use it for the actual exchange of information

     David Gaon

______________________________ Reply Separator _________________________________
Subject: RE: Re[2]: 2nd S/MIME BOF meeting minutes
Author:  Steve Dusse <[email-masked]> at smtp
Date:    4/15/97 2:24 PM

In the world of peer-to-peer store-and-forward communications (e.g. 
email) there really is no negotiation possible at "start of 
communications".  This is especially evident in the case of a multicast 
message, i.e. sending a message to a bunch of recipients.
     
In such an environment, negotiation can be done either out of band 
beforehand (e.g. by looking up some entries in a directory) or via 
exchange of email by the end users who are not always savvy enough to 
effectively negotiate encryption algorithms and key sizes.  It was our 
intent when creating S/MIME to provide some base level of 
interoperability possible among all S/MIME-enabled user agents (i.e. the 
"MUSTS") and an easy path to negotiating the use of the strongest 
possible encryption where both ends are capable (i.e. the "SHOULDS").
     
-steve
     
>----------
>From:  David Gaon[SMTP:[email-masked]] 
>Sent:  Tuesday, April 15, 1997 10:13 AM
>To:  [email-masked]; [email-masked]; [email-masked]; Charles Breed 
>Subject:  Re[2]: 2nd S/MIME BOF meeting minutes
>
>     I do not understand why there must be a ""MUST profiles"" albeit for 
>     interoperability.
>     
>     Why can't 2 communicating identities negotiate and/or agree (perhaps 
>     a-priori) on an algorithm to secure their communications ??
>     All we need then is an i.d. code to identify the algorithms or a field 
>     that says this is negotiable at start of communications.
>     
>     Will someone help clarify this ! 
>     
>     David Gaon
>
>
>______________________________ Reply Separator 
>_________________________________
>Subject: Re: 2nd S/MIME BOF meeting minutes 
>Author:  Charles Breed <[email-masked]> at smtp 
>Date:    4/14/97 2:53 PM
>
>
> (The meeting was on April 9th, not the 8th...) 
>     
>The issues brought up by the IETF Security Area Director, Jeff Schiller, were 
>inevitable. S/MIME needs to exist with open, non-proprietary profiles as well 
>as
>profile that require licensing of patented algorithms, especially if one 
>wants 
>an elliptic curve algorithm.
>     
>     
>I propose the following changes to move this forward as a working group... 
>     
>1. RSA to give the 'S/MIME' trade mark to a neutral, non-profit organization 
>that's willing to arbitrate interoperability disputes. (or change the name of 
>the spec)
>     
>2. The only MUST profile should be RSA (Public Key), 3DES (Symmetric), SHA-1 
>(Message Digest)
>     
>3. Unfortunately, the MUST profile (for interoperability), will be US export 
>controlled. US export requirements should NOT be imposed upon an 
>international 
>standards organization. (Why should someone in Japan be forced to uses 40-bit 
>weak crypto to communicate with someone in Germany, if their profile is 
>unknown?) It is more dangerous to resort to weak crypto than nothing at all. 
>Some folks would want to be able to state, "Do not send me anything less than 
>128-bit".
>     
>4. PKCS #7 to be an informational rfc prior to S/MIME final call 
>     
>5. The spec should allow for handling of additional certificate types, such 
>as 
>the SPKI (SDSI) working group proposed data structure. 
>     
>     
>regards,
>Charles Breed
>     
>     
>     
>     
>     
>At 01:24 PM 4/12/97 -0700, Laurence Lundblade wrote: 
>>Second S/MIME BOF Meeting Minutes
>>38th IETF, Memphis
>>April 8, 1997
>>
>>Chairperson: Paul Hoffman
>>
>>Agenda:
>>  Introduction
>>  Status of Drafts
>>  Status of S/MIME products
>>  Working group formation
>>  Issues with current draft
>>
>>Mailing lists:
>>  [email-masked] - for discussion of the drafts
>>  [email-masked] - for discussion of developer issues 
>>
>>A couple of issues were brought up before we got started on the Agenda: 
>>  A question was raised as to whether work on the secuity multiparts 
>>standard 
>>  would be pulled into this working group. The problem raised was that they 
>>  require exact bit integrity for the signature to remain valid, and this is 
>>  particularly a problem with the multipart/related MIME type.
>>
>>  Mention was made that the charter was posted to the mailing lists after 
>>the 
>>  previous BOF and resulted in little response 
>>
>>
>>Status of Drafts (Paul Hofman):
>>  Two drafts were submitted to the IETF. One is a combination of the 
>>previous S/MIME
>>  message specification and the interoperability guide. The other is a 
>>certificate
>>  specification that was split out from the previous documents.  Each draft 
>>lists open
>>  issues.
>>
>>
>>Products status (Blake Ramsdel):
>>  Shipping: Entrust, ConnectSoft, Deming/WorldTalk, Frontier, OpenSoft 
>>  Near Shipping: Netscape Messenger, Internet Explorer 4 (Microsoft) 
>>
>>
>>Working group (these notes are cronological; the discussion was chaotic): 
>>  Intro slide shows:
>>    - A working group will result in better publicity in the IETF 
>>    - Better interaction with IETF
>>    - Greater vendor confidence
>>    - tried to form 3 mo. ago with little response (to charter) 
>>
>> Jeff Schiller, security area director, responds:
>>     Purpose is to make a standard, not to get publicity. This BOF must 
>>focus and make
>>     a decision. A charter must say the working group desires to create a 
>>standard because
>>     working groups are only for creating standards. There cannot be 
>>another BOF.
>>
>>     Also, RSA needs to relinquish change control 
>>
>>  Other issues brought up (chronological order):
>>     Vendors must follow what this working group does, or there is no point 
>>in having
>>     this working group.
>>
>>     Tim Matthews of RSA said the main reason for control over the S/MIME 
>>name was to
>>     gaurantee interoperability between implementations that are labeled 
>>S/MIME,
>>     but would be willing to turn over control of the name if 
>>interoperability was
>>     otherwise gauranteed
>>
>>     The current document requires intellectual property rights (IPR) of 
>>RSA. 
>>
>>     The reason RC2 is used is because it has been cleared by the commerce 
>>department
>>     for export. It is very easy for a vendor to export crypto with 40 bit 
>>RC2. No other
>>     algorithm has the same support (yet). 
>>
>>     (editors note - RC2 is a trade secret of RSA. It is not patented. 
>>Trade secrets are
>>       indefinite as long as they are protected, but it is the 
>>responsibility of the owner
>>       to protect them)
>>
>>     Some suggest the RC2 trade secret is gone 
>>
>>     A poll asked whether implementors were willing to give change control 
>>to the IETF.
>>     Many were willing. Some reasons given for not forming a working group 
>>to produce a
>>     standard (and leaving control with RSA) were that we can't get through 
>>the process, or
>>     that the result has some security hole. 
>>
>>     The process should not be a rubber stamp process. 
>>
>>     A point was made that the standard should be open on the issue of 
>>algorithms <applause>.
>>
>>     A point was made that we can't do that with current algorithms (most 
>>are encumbered).
>>
>>     A point was made that acknowledged that interoperability with current 
>>implementations
>>    was OK, but that 40 bit crypto is unacceptably insecure for some 
>>communities. This
>>    point was quickly countered that the debate over the sufficiency of 40 
>>bits was out of the
>>    scope of this meeting.
>>
>>    We have several choices
>>      - S/MIME evolves to be non-proprietary (e.g. stops requiring 
>>proprietary algs)
>>      - The right to algorithms it uses are released 
>>      - Do something completely different (e.g., MOSS)
>>    Both profiles in S/MIME currently require RC2 (proprietary) 
>>    There is a similar problem with TLS
>>
>>    Jeff suggests one solution that would be acceptable to him (which 
>>doesn't mean the IESG and
>>    IAB approve (yet)) is to have a single profile that doesn't include 
>>RC2, 40 bits.
>>
>>    A poll showed this would be acceptable and there was no decension (RSA 
>>representive obstains)
>>
>>    A point was made that non-US implentors can implement technology that 
>>is deemed not
>>    exportable in the US.
>>
>>    Suggestion that we go ahead without RC2.... Some questioned whether or 
>>not this would
>>    be "S/MIME".
>>
>>   (editor: now we're getting to the nitty gritty...) 
>>
>>    Jeff (area directory): S/MIME IPR issue must be resolved by July 1, 
>>1997 or working group
>>    cannot be formed
>>
>>    Tim (RSA Inc.): RSA can work with that time frame 
>>
>>    Jeff's requirements:
>>      Interoperability is a requirement, therefore some algorithms must be 
>>mandatory. Have a
>>      strong bias towards open algorithms, but can accept some that are 
>>not. There are open
>>      symmetric algorithms (editor: that can be used instead of RC2) 
>>
>>      Control must be with in the IETF, e.g., IETF "has a license to do 
>>S/MIME" and IETF says what
>>      the protocol is.
>>
>>      PKCS7 isn't an issue. It can be published as an informational RFC. 
>>
>>      The patents on the RSA algorithm are not an issue because they will 
>>expire. Thus the
>>      issue is with the RC2 algorithm because it is a trade secret which 
>>will never expire.
>>      RSA has not disavowed its IPR for RC2 and it could go on for a long 
>>time.
>>
>>(editor's summary: RSA must resolve two issues before a working group can 
>>begin work
>> towards a standard. 1) S/MIME must not rely on a trade secret (RC2), 2) 
>>Change control
>> must be with the IETF (e.g., the rights to the "S/MIME" trademark must be 
>>neutrally held.)
>> These must be resolved by July 1, 1997.  The RSA representive acknowledged 
>>this).
>>
>>
>>
>>On to issues (with a few minutes left)
>>  Laurence presented proposal for reorganization of section 3 of the 
>>document. The reorganization
>>  was for the sake of clarity and to separate the definition of the message 
>>formats from the rationale
>>  for their use. There was general ascent towards the proposal, though the 
>>meeting began to break up.
>>
>>  At this point we gave up the meeting was breaking up 
>>
>>  One last issue raised - does the inside object really have to be MIME 
>>encoded or not (editor it
>>  wasn't clear whether this was the issue of transfer encoding or the issue 
>>of MIME vs 822).
>>
>>
>>
>>
>>
>
>

Date: Tue, 15 Apr 1997 11:31:49 -0700
To: [email-masked], "Frederik H. Andersen" <[email-masked]>
From: Charles Breed <[email-masked]>
Subject: Re: 2nd S/MIME BOF meeting minutes 
Cc: [email-masked]
Sender: [email-masked]

	:note to Paul H, we'll move this off this list...

The way I see it...

- Yes, freeware versions of pgp are available worldwide
- pgp needs to be enhanced to 'handle' other certificates / capabilities
- The name PGP is trademarked, just like S/MIME
- RSAref is only distributed from the MIT site, an agreement between RSA and MIT
- RSAref is strictly for non-commercial use, not for resell
- S/MIME was derived from a competing group, without any compatibility with pgp
- A single, non-proprietary, open, IETF approved format / data structure that we can 
  all agree upon would be a very good thing!(merged DMS, MSP, PEM, MOSS, S/MIME, PGP/MIME)
- The community needs buy in from all the major email vendors for secure email to become
  a reality.
- This reminds me of the pathetic battles between Fast Ethernet, 100VG, CDDI, 25mbATM...
  (a Rodney King saying comes to mind...)

Charles Breed

At 12:26 PM 4/15/97 -0400, Uri Blumenthal wrote:
>>>>>> "F" == Frederik H Andersen <[email-masked]> writes:
>
>    F> Eh, you mean that pgp is not FREELY AVAILABLE? I am probably
>    F> wrong, but I believed that it was??  I know, that these
>    F> versions are meant for non-commercial use - is that the
>    F> problem?
>
>Yes it is, and yes I was wrong (I thought of a different technology :-).
>
>    F> What about approaching pgp.com about this as the plan seems to
>    F> be with the RSA secret code!
>
>(:-)
>
>    F> Who could prohibit a free reference implementation
>    F> f.ex. outside US? Why could that not be freely imported to US?
>
>It is already done (see pgp263i.tar.gz on your favorite FTP server),
>and I think I saw it within the US (am not sure though :-).
>
>    F> What is the problem in US?  RSA again?
>
>Yeah, it might be, but there are freely available PGP sources in
>the US as well. They use RSAREF and thus are legal.
>
>    F> I'm probably terrible wrong!
>
>He-he. No, you are not! How about that for a change? (:-)
>
>In light of the above - what are the reasons for not making
>PGP a mandatory format? [Apologies if this has already been
>discussed at length,  in which case  just kindly e-mail the
>replies, with the appropriate NOSPAM correction.]
>
>
>Regards,                   [To reply, remove "NOSPAM!" from the 
>Uri                         "Reply-To:" field]
>-=-=-==-=-=-		[email-masked]
><Disclaimer>
>
>

From: Steve Dusse <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'David Gaon'" <[email-masked]>
Subject: RE: Re[2]: 2nd S/MIME BOF meeting minutes
Date: Tue, 15 Apr 1997 11:26:34 -0700
Sender: [email-masked]

In the world of peer-to-peer store-and-forward communications (e.g.
email) there really is no negotiation possible at "start of
communications".  This is especially evident in the case of a multicast
message, i.e. sending a message to a bunch of recipients.

In such an environment, negotiation can be done either out of band
beforehand (e.g. by looking up some entries in a directory) or via
exchange of email by the end users who are not always savvy enough to
effectively negotiate encryption algorithms and key sizes.  It was our
intent when creating S/MIME to provide some base level of
interoperability possible among all S/MIME-enabled user agents (i.e. the
"MUSTS") and an easy path to negotiating the use of the strongest
possible encryption where both ends are capable (i.e. the "SHOULDS").

-steve

>----------
>From: 	David Gaon[SMTP:[email-masked]]
>Sent: 	Tuesday, April 15, 1997 10:13 AM
>To: 	[email-masked]; [email-masked]; [email-masked]; Charles Breed
>Subject: 	Re[2]: 2nd S/MIME BOF meeting minutes
>
>     I do not understand why there must be a ""MUST profiles"" albeit for 
>     interoperability.
>     
>     Why can't 2 communicating identities negotiate and/or agree (perhaps 
>     a-priori) on an algorithm to secure their communications ??
>     All we need then is an i.d. code to identify the algorithms or a field 
>     that says this is negotiable at start of communications.
>     
>     Will someone help clarify this !
>     
>     David Gaon
>
>
>______________________________ Reply Separator
>_________________________________
>Subject: Re: 2nd S/MIME BOF meeting minutes
>Author:  Charles Breed <[email-masked]> at smtp
>Date:    4/14/97 2:53 PM
>
>
> (The meeting was on April 9th, not the 8th...)
>     
>The issues brought up by the IETF Security Area Director, Jeff Schiller, were
>inevitable. S/MIME needs to exist with open, non-proprietary profiles as well
>as
>profile that require licensing of patented algorithms, especially if one
>wants 
>an elliptic curve algorithm.
>     
>     
>I propose the following changes to move this forward as a working group...
>     
>1. RSA to give the 'S/MIME' trade mark to a neutral, non-profit organization 
>that's willing to arbitrate interoperability disputes. (or change the name of
>the spec)
>     
>2. The only MUST profile should be RSA (Public Key), 3DES (Symmetric), SHA-1 
>(Message Digest)
>     
>3. Unfortunately, the MUST profile (for interoperability), will be US export 
>controlled. US export requirements should NOT be imposed upon an
>international 
>standards organization. (Why should someone in Japan be forced to uses 40-bit
>weak crypto to communicate with someone in Germany, if their profile is 
>unknown?) It is more dangerous to resort to weak crypto than nothing at all. 
>Some folks would want to be able to state, "Do not send me anything less than
>128-bit".
>     
>4. PKCS #7 to be an informational rfc prior to S/MIME final call
>     
>5. The spec should allow for handling of additional certificate types, such
>as 
>the SPKI (SDSI) working group proposed data structure.
>     
>     
>regards,
>Charles Breed
>     
>     
>     
>     
>     
>At 01:24 PM 4/12/97 -0700, Laurence Lundblade wrote: 
>>Second S/MIME BOF Meeting Minutes
>>38th IETF, Memphis
>>April 8, 1997
>>
>>Chairperson: Paul Hoffman
>>
>>Agenda:
>>  Introduction
>>  Status of Drafts
>>  Status of S/MIME products
>>  Working group formation
>>  Issues with current draft
>>
>>Mailing lists:
>>  [email-masked] - for discussion of the drafts
>>  [email-masked] - for discussion of developer issues 
>>
>>A couple of issues were brought up before we got started on the Agenda:
>>  A question was raised as to whether work on the secuity multiparts
>>standard 
>>  would be pulled into this working group. The problem raised was that they
>>  require exact bit integrity for the signature to remain valid, and this is
>>  particularly a problem with the multipart/related MIME type.
>>
>>  Mention was made that the charter was posted to the mailing lists after
>>the 
>>  previous BOF and resulted in little response
>>
>>
>>Status of Drafts (Paul Hofman):
>>  Two drafts were submitted to the IETF. One is a combination of the 
>>previous S/MIME
>>  message specification and the interoperability guide. The other is a 
>>certificate
>>  specification that was split out from the previous documents.  Each draft 
>>lists open
>>  issues.
>>
>>
>>Products status (Blake Ramsdel):
>>  Shipping: Entrust, ConnectSoft, Deming/WorldTalk, Frontier, OpenSoft 
>>  Near Shipping: Netscape Messenger, Internet Explorer 4 (Microsoft)
>>
>>
>>Working group (these notes are cronological; the discussion was chaotic): 
>>  Intro slide shows:
>>    - A working group will result in better publicity in the IETF 
>>    - Better interaction with IETF
>>    - Greater vendor confidence
>>    - tried to form 3 mo. ago with little response (to charter) 
>>
>> Jeff Schiller, security area director, responds:
>>     Purpose is to make a standard, not to get publicity. This BOF must 
>>focus and make
>>     a decision. A charter must say the working group desires to create a 
>>standard because
>>     working groups are only for creating standards. There cannot be 
>>another BOF.
>>
>>     Also, RSA needs to relinquish change control 
>>
>>  Other issues brought up (chronological order):
>>     Vendors must follow what this working group does, or there is no point 
>>in having
>>     this working group.
>>
>>     Tim Matthews of RSA said the main reason for control over the S/MIME 
>>name was to
>>     gaurantee interoperability between implementations that are labeled 
>>S/MIME,
>>     but would be willing to turn over control of the name if 
>>interoperability was
>>     otherwise gauranteed
>>
>>     The current document requires intellectual property rights (IPR) of
>>RSA. 
>>
>>     The reason RC2 is used is because it has been cleared by the commerce 
>>department
>>     for export. It is very easy for a vendor to export crypto with 40 bit 
>>RC2. No other
>>     algorithm has the same support (yet). 
>>
>>     (editors note - RC2 is a trade secret of RSA. It is not patented. 
>>Trade secrets are
>>       indefinite as long as they are protected, but it is the 
>>responsibility of the owner
>>       to protect them)
>>
>>     Some suggest the RC2 trade secret is gone 
>>
>>     A poll asked whether implementors were willing to give change control 
>>to the IETF.
>>     Many were willing. Some reasons given for not forming a working group 
>>to produce a
>>     standard (and leaving control with RSA) were that we can't get through 
>>the process, or
>>     that the result has some security hole. 
>>
>>     The process should not be a rubber stamp process. 
>>
>>     A point was made that the standard should be open on the issue of 
>>algorithms <applause>.
>>
>>     A point was made that we can't do that with current algorithms (most 
>>are encumbered).
>>
>>     A point was made that acknowledged that interoperability with current 
>>implementations
>>    was OK, but that 40 bit crypto is unacceptably insecure for some 
>>communities. This
>>    point was quickly countered that the debate over the sufficiency of 40 
>>bits was out of the
>>    scope of this meeting.
>>
>>    We have several choices
>>      - S/MIME evolves to be non-proprietary (e.g. stops requiring 
>>proprietary algs)
>>      - The right to algorithms it uses are released
>>      - Do something completely different (e.g., MOSS)
>>    Both profiles in S/MIME currently require RC2 (proprietary) 
>>    There is a similar problem with TLS
>>
>>    Jeff suggests one solution that would be acceptable to him (which 
>>doesn't mean the IESG and
>>    IAB approve (yet)) is to have a single profile that doesn't include 
>>RC2, 40 bits.
>>
>>    A poll showed this would be acceptable and there was no decension (RSA 
>>representive obstains)
>>
>>    A point was made that non-US implentors can implement technology that 
>>is deemed not
>>    exportable in the US.
>>
>>    Suggestion that we go ahead without RC2.... Some questioned whether or 
>>not this would
>>    be "S/MIME".
>>
>>   (editor: now we're getting to the nitty gritty...) 
>>
>>    Jeff (area directory): S/MIME IPR issue must be resolved by July 1, 
>>1997 or working group
>>    cannot be formed
>>
>>    Tim (RSA Inc.): RSA can work with that time frame 
>>
>>    Jeff's requirements:
>>      Interoperability is a requirement, therefore some algorithms must be 
>>mandatory. Have a
>>      strong bias towards open algorithms, but can accept some that are 
>>not. There are open
>>      symmetric algorithms (editor: that can be used instead of RC2) 
>>
>>      Control must be with in the IETF, e.g., IETF "has a license to do 
>>S/MIME" and IETF says what
>>      the protocol is.
>>
>>      PKCS7 isn't an issue. It can be published as an informational RFC. 
>>
>>      The patents on the RSA algorithm are not an issue because they will 
>>expire. Thus the
>>      issue is with the RC2 algorithm because it is a trade secret which 
>>will never expire.
>>      RSA has not disavowed its IPR for RC2 and it could go on for a long
>>time.
>>
>>(editor's summary: RSA must resolve two issues before a working group can 
>>begin work
>> towards a standard. 1) S/MIME must not rely on a trade secret (RC2), 2) 
>>Change control
>> must be with the IETF (e.g., the rights to the "S/MIME" trademark must be 
>>neutrally held.)
>> These must be resolved by July 1, 1997.  The RSA representive acknowledged 
>>this).
>>
>>
>>
>>On to issues (with a few minutes left)
>>  Laurence presented proposal for reorganization of section 3 of the 
>>document. The reorganization
>>  was for the sake of clarity and to separate the definition of the message 
>>formats from the rationale
>>  for their use. There was general ascent towards the proposal, though the 
>>meeting began to break up.
>>
>>  At this point we gave up the meeting was breaking up 
>>
>>  One last issue raised - does the inside object really have to be MIME 
>>encoded or not (editor it
>>  wasn't clear whether this was the issue of transfer encoding or the issue 
>>of MIME vs 822).
>>
>>
>>
>>
>>
>
>

Date: Tue, 15 Apr 1997 10:09:47 -0700
To: "David Gaon" <[email-masked]>, [email-masked], Charles Breed <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re[2]: 2nd S/MIME BOF meeting minutes
Sender: [email-masked]

OK, this is a standards issue, so this discussion should be on ietf-smime.

You said it yourself, "albeit for interoperability".  We don't want a
standard that doesn't guarantee some level of interoperability - that is
that two parties are guaranteed to be able to negotiate down to some set of
algorithms.

LL

At 12:13 PM -0500 4/15/97, David Gaon wrote:
>     I do not understand why there must be a ""MUST profiles"" albeit for
>     interoperability.
>
>     Why can't 2 communicating identities negotiate and/or agree (perhaps
>     a-priori) on an algorithm to secure their communications ??
>     All we need then is an i.d. code to identify the algorithms or a field
>     that says this is negotiable at start of communications.
>
>     Will someone help clarify this !
>
>     David Gaon
>
>
>______________________________ Reply Separator
>_________________________________
>Subject: Re: 2nd S/MIME BOF meeting minutes
>Author:  Charles Breed <[email-masked]> at smtp
>Date:    4/14/97 2:53 PM
>
>
> (The meeting was on April 9th, not the 8th...)
>
>The issues brought up by the IETF Security Area Director, Jeff Schiller, were
>inevitable. S/MIME needs to exist with open, non-proprietary profiles as
>well as
>profile that require licensing of patented algorithms, especially if one
>wants
>an elliptic curve algorithm.
>
>
>I propose the following changes to move this forward as a working group...
>
>1. RSA to give the 'S/MIME' trade mark to a neutral, non-profit organization
>that's willing to arbitrate interoperability disputes. (or change the name of
>the spec)
>
>2. The only MUST profile should be RSA (Public Key), 3DES (Symmetric), SHA-1
>(Message Digest)
>
>3. Unfortunately, the MUST profile (for interoperability), will be US export
>controlled. US export requirements should NOT be imposed upon an
>international
>standards organization. (Why should someone in Japan be forced to uses 40-bit
>weak crypto to communicate with someone in Germany, if their profile is
>unknown?) It is more dangerous to resort to weak crypto than nothing at all.
>Some folks would want to be able to state, "Do not send me anything less than
>128-bit".
>
>4. PKCS #7 to be an informational rfc prior to S/MIME final call
>
>5. The spec should allow for handling of additional certificate types,
>such as
>the SPKI (SDSI) working group proposed data structure.
>
>
>regards,
>Charles Breed
>
>
>
>
>
>At 01:24 PM 4/12/97 -0700, Laurence Lundblade wrote:
>>Second S/MIME BOF Meeting Minutes
>>38th IETF, Memphis
>>April 8, 1997
>>
>>Chairperson: Paul Hoffman
>>
>>Agenda:
>>  Introduction
>>  Status of Drafts
>>  Status of S/MIME products
>>  Working group formation
>>  Issues with current draft
>>
>>Mailing lists:
>>  [email-masked] - for discussion of the drafts
>>  [email-masked] - for discussion of developer issues
>>
>>A couple of issues were brought up before we got started on the Agenda:
>>  A question was raised as to whether work on the secuity multiparts
>>standard
>>  would be pulled into this working group. The problem raised was that they
>>  require exact bit integrity for the signature to remain valid, and this is
>>  particularly a problem with the multipart/related MIME type.
>>
>>  Mention was made that the charter was posted to the mailing lists after
>>the
>>  previous BOF and resulted in little response
>>
>>
>>Status of Drafts (Paul Hofman):
>>  Two drafts were submitted to the IETF. One is a combination of the
>>previous S/MIME
>>  message specification and the interoperability guide. The other is a
>>certificate
>>  specification that was split out from the previous documents.  Each draft
>>lists open
>>  issues.
>>
>>
>>Products status (Blake Ramsdel):
>>  Shipping: Entrust, ConnectSoft, Deming/WorldTalk, Frontier, OpenSoft
>>  Near Shipping: Netscape Messenger, Internet Explorer 4 (Microsoft)
>>
>>
>>Working group (these notes are cronological; the discussion was chaotic):
>>  Intro slide shows:
>>    - A working group will result in better publicity in the IETF
>>    - Better interaction with IETF
>>    - Greater vendor confidence
>>    - tried to form 3 mo. ago with little response (to charter)
>>
>> Jeff Schiller, security area director, responds:
>>     Purpose is to make a standard, not to get publicity. This BOF must
>>focus and make
>>     a decision. A charter must say the working group desires to create a
>>standard because
>>     working groups are only for creating standards. There cannot be
>>another BOF.
>>
>>     Also, RSA needs to relinquish change control
>>
>>  Other issues brought up (chronological order):
>>     Vendors must follow what this working group does, or there is no point
>>in having
>>     this working group.
>>
>>     Tim Matthews of RSA said the main reason for control over the S/MIME
>>name was to
>>     gaurantee interoperability between implementations that are labeled
>>S/MIME,
>>     but would be willing to turn over control of the name if
>>interoperability was
>>     otherwise gauranteed
>>
>>     The current document requires intellectual property rights (IPR) of
>>RSA.
>>
>>     The reason RC2 is used is because it has been cleared by the commerce
>>department
>>     for export. It is very easy for a vendor to export crypto with 40 bit
>>RC2. No other
>>     algorithm has the same support (yet).
>>
>>     (editors note - RC2 is a trade secret of RSA. It is not patented.
>>Trade secrets are
>>       indefinite as long as they are protected, but it is the
>>responsibility of the owner
>>       to protect them)
>>
>>     Some suggest the RC2 trade secret is gone
>>
>>     A poll asked whether implementors were willing to give change control
>>to the IETF.
>>     Many were willing. Some reasons given for not forming a working group
>>to produce a
>>     standard (and leaving control with RSA) were that we can't get through
>>the process, or
>>     that the result has some security hole.
>>
>>     The process should not be a rubber stamp process.
>>
>>     A point was made that the standard should be open on the issue of
>>algorithms <applause>.
>>
>>     A point was made that we can't do that with current algorithms (most
>>are encumbered).
>>
>>     A point was made that acknowledged that interoperability with current
>>implementations
>>    was OK, but that 40 bit crypto is unacceptably insecure for some
>>communities. This
>>    point was quickly countered that the debate over the sufficiency of 40
>>bits was out of the
>>    scope of this meeting.
>>
>>    We have several choices
>>      - S/MIME evolves to be non-proprietary (e.g. stops requiring
>>proprietary algs)
>>      - The right to algorithms it uses are released
>>      - Do something completely different (e.g., MOSS)
>>    Both profiles in S/MIME currently require RC2 (proprietary)
>>    There is a similar problem with TLS
>>
>>    Jeff suggests one solution that would be acceptable to him (which
>>doesn't mean the IESG and
>>    IAB approve (yet)) is to have a single profile that doesn't include
>>RC2, 40 bits.
>>
>>    A poll showed this would be acceptable and there was no decension (RSA
>>representive obstains)
>>
>>    A point was made that non-US implentors can implement technology that
>>is deemed not
>>    exportable in the US.
>>
>>    Suggestion that we go ahead without RC2.... Some questioned whether or
>>not this would
>>    be "S/MIME".
>>
>>   (editor: now we're getting to the nitty gritty...)
>>
>>    Jeff (area directory): S/MIME IPR issue must be resolved by July 1,
>>1997 or working group
>>    cannot be formed
>>
>>    Tim (RSA Inc.): RSA can work with that time frame
>>
>>    Jeff's requirements:
>>      Interoperability is a requirement, therefore some algorithms must be
>>mandatory. Have a
>>      strong bias towards open algorithms, but can accept some that are
>>not. There are open
>>      symmetric algorithms (editor: that can be used instead of RC2)
>>
>>      Control must be with in the IETF, e.g., IETF "has a license to do
>>S/MIME" and IETF says what
>>      the protocol is.
>>
>>      PKCS7 isn't an issue. It can be published as an informational RFC.
>>
>>      The patents on the RSA algorithm are not an issue because they will
>>expire. Thus the
>>      issue is with the RC2 algorithm because it is a trade secret which
>>will never expire.
>>      RSA has not disavowed its IPR for RC2 and it could go on for a long
>>time.
>>
>>(editor's summary: RSA must resolve two issues before a working group can
>>begin work
>> towards a standard. 1) S/MIME must not rely on a trade secret (RC2), 2)
>>Change control
>> must be with the IETF (e.g., the rights to the "S/MIME" trademark must be
>>neutrally held.)
>> These must be resolved by July 1, 1997.  The RSA representive acknowledged
>>this).
>>
>>
>>
>>On to issues (with a few minutes left)
>>  Laurence presented proposal for reorganization of section 3 of the
>>document. The reorganization
>>  was for the sake of clarity and to separate the definition of the message
>>formats from the rationale
>>  for their use. There was general ascent towards the proposal, though the
>>meeting began to break up.
>>
>>  At this point we gave up the meeting was breaking up
>>
>>  One last issue raised - does the inside object really have to be MIME
>>encoded or not (editor it
>>  wasn't clear whether this was the issue of transfer encoding or the issue
>>of MIME vs 822).
>>
>>
>>
>>
>>

Date: Tue, 15 Apr 1997 12:26:52 -0400
From: Uri Blumenthal <[email-masked]>
To: "Frederik H. Andersen" <[email-masked]>
Cc: [email-masked]
Subject: Re: 2nd S/MIME BOF meeting minutes 
Reply-To: [email-masked]
Sender: [email-masked]

>>>>> "F" == Frederik H Andersen <[email-masked]> writes:

    F> Eh, you mean that pgp is not FREELY AVAILABLE? I am probably
    F> wrong, but I believed that it was??  I know, that these
    F> versions are meant for non-commercial use - is that the
    F> problem?

Yes it is, and yes I was wrong (I thought of a different technology :-).

    F> What about approaching pgp.com about this as the plan seems to
    F> be with the RSA secret code!

(:-)

    F> Who could prohibit a free reference implementation
    F> f.ex. outside US? Why could that not be freely imported to US?

It is already done (see pgp263i.tar.gz on your favorite FTP server),
and I think I saw it within the US (am not sure though :-).

    F> What is the problem in US?  RSA again?

Yeah, it might be, but there are freely available PGP sources in
the US as well. They use RSAREF and thus are legal.

    F> I'm probably terrible wrong!

He-he. No, you are not! How about that for a change? (:-)

In light of the above - what are the reasons for not making
PGP a mandatory format? [Apologies if this has already been
discussed at length,  in which case  just kindly e-mail the
replies, with the appropriate NOSPAM correction.]

Regards,                   [To reply, remove "NOSPAM!" from the 
Uri                         "Reply-To:" field]
-=-=-==-=-=-		[email-masked]
<Disclaimer>

Date: Tue, 15 Apr 97 12:13:09 EST
From: "David Gaon" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], Charles Breed <[email-masked]>
Subject: Re[2]: 2nd S/MIME BOF meeting minutes
Sender: [email-masked]

     I do not understand why there must be a ""MUST profiles"" albeit for 
     interoperability.
     
     Why can't 2 communicating identities negotiate and/or agree (perhaps 
     a-priori) on an algorithm to secure their communications ??
     All we need then is an i.d. code to identify the algorithms or a field 
     that says this is negotiable at start of communications.
     
     Will someone help clarify this !
     
     David Gaon

______________________________ Reply Separator _________________________________
Subject: Re: 2nd S/MIME BOF meeting minutes
Author:  Charles Breed <[email-masked]> at smtp
Date:    4/14/97 2:53 PM

 (The meeting was on April 9th, not the 8th...)
     
The issues brought up by the IETF Security Area Director, Jeff Schiller, were 
inevitable. S/MIME needs to exist with open, non-proprietary profiles as well as
profile that require licensing of patented algorithms, especially if one wants 
an elliptic curve algorithm.

I propose the following changes to move this forward as a working group...
     
1. RSA to give the 'S/MIME' trade mark to a neutral, non-profit organization 
that's willing to arbitrate interoperability disputes. (or change the name of 
the spec)
     
2. The only MUST profile should be RSA (Public Key), 3DES (Symmetric), SHA-1 
(Message Digest)
     
3. Unfortunately, the MUST profile (for interoperability), will be US export 
controlled. US export requirements should NOT be imposed upon an international 
standards organization. (Why should someone in Japan be forced to uses 40-bit 
weak crypto to communicate with someone in Germany, if their profile is 
unknown?) It is more dangerous to resort to weak crypto than nothing at all. 
Some folks would want to be able to state, "Do not send me anything less than 
128-bit".
     
4. PKCS #7 to be an informational rfc prior to S/MIME final call
     
5. The spec should allow for handling of additional certificate types, such as 
the SPKI (SDSI) working group proposed data structure.

regards,
Charles Breed

     

At 01:24 PM 4/12/97 -0700, Laurence Lundblade wrote: 
>Second S/MIME BOF Meeting Minutes
>38th IETF, Memphis
>April 8, 1997
>
>Chairperson: Paul Hoffman
>
>Agenda:
>  Introduction
>  Status of Drafts
>  Status of S/MIME products
>  Working group formation
>  Issues with current draft
>
>Mailing lists:
>  [email-masked] - for discussion of the drafts
>  [email-masked] - for discussion of developer issues 
>
>A couple of issues were brought up before we got started on the Agenda:
>  A question was raised as to whether work on the secuity multiparts standard 
>  would be pulled into this working group. The problem raised was that they
>  require exact bit integrity for the signature to remain valid, and this is 
>  particularly a problem with the multipart/related MIME type.
>
>  Mention was made that the charter was posted to the mailing lists after the 
>  previous BOF and resulted in little response
>
>
>Status of Drafts (Paul Hofman):
>  Two drafts were submitted to the IETF. One is a combination of the 
>previous S/MIME
>  message specification and the interoperability guide. The other is a 
>certificate
>  specification that was split out from the previous documents.  Each draft 
>lists open
>  issues.
>
>
>Products status (Blake Ramsdel):
>  Shipping: Entrust, ConnectSoft, Deming/WorldTalk, Frontier, OpenSoft 
>  Near Shipping: Netscape Messenger, Internet Explorer 4 (Microsoft)
>
>
>Working group (these notes are cronological; the discussion was chaotic): 
>  Intro slide shows:
>    - A working group will result in better publicity in the IETF 
>    - Better interaction with IETF
>    - Greater vendor confidence
>    - tried to form 3 mo. ago with little response (to charter) 
>
> Jeff Schiller, security area director, responds:
>     Purpose is to make a standard, not to get publicity. This BOF must 
>focus and make
>     a decision. A charter must say the working group desires to create a 
>standard because
>     working groups are only for creating standards. There cannot be 
>another BOF.
>
>     Also, RSA needs to relinquish change control 
>
>  Other issues brought up (chronological order):
>     Vendors must follow what this working group does, or there is no point 
>in having
>     this working group.
>
>     Tim Matthews of RSA said the main reason for control over the S/MIME 
>name was to
>     gaurantee interoperability between implementations that are labeled 
>S/MIME,
>     but would be willing to turn over control of the name if 
>interoperability was
>     otherwise gauranteed
>
>     The current document requires intellectual property rights (IPR) of RSA. 
>
>     The reason RC2 is used is because it has been cleared by the commerce 
>department
>     for export. It is very easy for a vendor to export crypto with 40 bit 
>RC2. No other
>     algorithm has the same support (yet). 
>
>     (editors note - RC2 is a trade secret of RSA. It is not patented. 
>Trade secrets are
>       indefinite as long as they are protected, but it is the 
>responsibility of the owner
>       to protect them)
>
>     Some suggest the RC2 trade secret is gone 
>
>     A poll asked whether implementors were willing to give change control 
>to the IETF.
>     Many were willing. Some reasons given for not forming a working group 
>to produce a
>     standard (and leaving control with RSA) were that we can't get through 
>the process, or
>     that the result has some security hole. 
>
>     The process should not be a rubber stamp process. 
>
>     A point was made that the standard should be open on the issue of 
>algorithms <applause>.
>
>     A point was made that we can't do that with current algorithms (most 
>are encumbered).
>
>     A point was made that acknowledged that interoperability with current 
>implementations
>    was OK, but that 40 bit crypto is unacceptably insecure for some 
>communities. This
>    point was quickly countered that the debate over the sufficiency of 40 
>bits was out of the
>    scope of this meeting.
>
>    We have several choices
>      - S/MIME evolves to be non-proprietary (e.g. stops requiring 
>proprietary algs)
>      - The right to algorithms it uses are released
>      - Do something completely different (e.g., MOSS)
>    Both profiles in S/MIME currently require RC2 (proprietary) 
>    There is a similar problem with TLS
>
>    Jeff suggests one solution that would be acceptable to him (which 
>doesn't mean the IESG and
>    IAB approve (yet)) is to have a single profile that doesn't include 
>RC2, 40 bits.
>
>    A poll showed this would be acceptable and there was no decension (RSA 
>representive obstains)
>
>    A point was made that non-US implentors can implement technology that 
>is deemed not
>    exportable in the US.
>
>    Suggestion that we go ahead without RC2.... Some questioned whether or 
>not this would
>    be "S/MIME".
>
>   (editor: now we're getting to the nitty gritty...) 
>
>    Jeff (area directory): S/MIME IPR issue must be resolved by July 1, 
>1997 or working group
>    cannot be formed
>
>    Tim (RSA Inc.): RSA can work with that time frame 
>
>    Jeff's requirements:
>      Interoperability is a requirement, therefore some algorithms must be 
>mandatory. Have a
>      strong bias towards open algorithms, but can accept some that are 
>not. There are open
>      symmetric algorithms (editor: that can be used instead of RC2) 
>
>      Control must be with in the IETF, e.g., IETF "has a license to do 
>S/MIME" and IETF says what
>      the protocol is.
>
>      PKCS7 isn't an issue. It can be published as an informational RFC. 
>
>      The patents on the RSA algorithm are not an issue because they will 
>expire. Thus the
>      issue is with the RC2 algorithm because it is a trade secret which 
>will never expire.
>      RSA has not disavowed its IPR for RC2 and it could go on for a long time.
>
>(editor's summary: RSA must resolve two issues before a working group can 
>begin work
> towards a standard. 1) S/MIME must not rely on a trade secret (RC2), 2) 
>Change control
> must be with the IETF (e.g., the rights to the "S/MIME" trademark must be 
>neutrally held.)
> These must be resolved by July 1, 1997.  The RSA representive acknowledged 
>this).
>
>
>
>On to issues (with a few minutes left)
>  Laurence presented proposal for reorganization of section 3 of the 
>document. The reorganization
>  was for the sake of clarity and to separate the definition of the message 
>formats from the rationale
>  for their use. There was general ascent towards the proposal, though the 
>meeting began to break up.
>
>  At this point we gave up the meeting was breaking up 
>
>  One last issue raised - does the inside object really have to be MIME 
>encoded or not (editor it
>  wasn't clear whether this was the issue of transfer encoding or the issue 
>of MIME vs 822).
>
>
>
>
>

To: [email-masked]
Subject: Re: 2nd S/MIME BOF meeting minutes 
Date: Tue, 15 Apr 1997 18:03:29 +0200
From: "Frederik H. Andersen" <[email-masked]>
Sender: [email-masked]

On Tue, 15 Apr 1997 11:13:35 -0400  Uri Blumenthal wrote:
> Because IETF has a long tradition NOT to require a technology 
> that is not FREELY AVAILABLE?
> 

Eh, you mean that pgp is not FREELY AVAILABLE? I am probably wrong,
but I believed that it was??  I know, that these versions are meant for
non-commercial use - is that the problem?

What about approaching pgp.com about this as the plan seems to be with the
RSA secret code!

At least the pgp code is not secret!  The techniques are well known. Who
could prohibit a free reference implementation f.ex. outside US?  Why
could that not be freely imported to US? What is the problem in US?
RSA again?

I'm probably terrible wrong!

/Frederik

-- 

------------------------------------------------------------------
Frederik H. Andersen            Phone:  +45 42 84 50 11           
Dansk Data Elektronik A/S       Fax:    +45 42 84 52 20           
Herlev Hovedgade 199            Email:  [email-masked] (MIME accepted)
DK-2730 Herlev, DENMARK
PGP Fingerprint:  6B BC FB 45 E4 69 CE A2  63 E1 62 1F 0C 65 C2 E4
------------------------------------------------------------------

	

Date: Tue, 15 Apr 1997 08:12:49 -0700
To: [email-masked], [email-masked]
From: Laurence Lundblade <[email-masked]>
Subject: 2nd S/MIME BOF meeting minutes - corrections
Sender: [email-masked]

(We should probably keep this only on the ietf-smime list, but since I
posted to both...)

Two little corrections:
  Blake Ramsdell was co-chair
  Deming/Worldtalk does not have a capital "T".

LL

Date: Tue, 15 Apr 1997 11:13:35 -0400
From: Uri Blumenthal <[email-masked]>
To: "Frederik H. Andersen" <[email-masked]>
Cc: [email-masked]
Subject: Re: 2nd S/MIME BOF meeting minutes 
Reply-To: [email-masked]
Sender: [email-masked]

>>>>> "F" == Frederik H Andersen <[email-masked]> writes:

    F> What I find very difficult to understand is, why the
    F> technology: - which is the defacto standard...........
    F> allows almost arbitrarily strong crypto is not considered for
    F> the MUST technology?

Because IETF has a long tradition NOT to require a technology 
that is not FREELY AVAILABLE?

    F> Another thing, is it not true, assuming the technology is
    F> available, that nothing prevents a user in US and a user
    F> outside US to communicate using stong crypto ( e.g. 128 bit
    F> keys)?

Yes, this is true, to the best of my knowledge.

Regards,                   [To reply, remove "NOSPAM!" from the 
Uri                         "Reply-To:" field]
-=-=-==-=-=-		[email-masked]
<Disclaimer>

To: [email-masked]
Subject: Re: 2nd S/MIME BOF meeting minutes 
Date: Tue, 15 Apr 1997 10:36:21 +0200
From: "Frederik H. Andersen" <[email-masked]>
Sender: [email-masked]

[email-masked] said:
> 3. Unfortunately, the MUST profile (for interoperability), will be US
> export controlled. US export requirements should NOT be imposed upon
> an international standards organization. (Why should someone in Japan
> be forced to uses 40-bit weak crypto to communicate with someone in
> Germany, if their profile is unknown?) It is more dangerous to resort
> to weak crypto than nothing 

What I find very difficult to understand is, why the technology:
- which is the defacto standard
- the most widely used (world wide)
- which is not suffering from the US-export equirements (as it is already
  available outside US)
- which allows almost arbitrarily strong crypto 
is not considered for the MUST technology?

Another thing, is it not true, assuming the technology is available, that
nothing prevents a user in US and a user outside US to communicate using
stong crypto ( e.g. 128 bit keys)?

/Frederik

-- 

------------------------------------------------------------------
Frederik H. Andersen            Phone:  +45 42 84 50 11           
Dansk Data Elektronik A/S       Fax:    +45 42 84 52 20           
Herlev Hovedgade 199            Email:  [email-masked] (MIME accepted)
DK-2730 Herlev, DENMARK
PGP Fingerprint:  6B BC FB 45 E4 69 CE A2  63 E1 62 1F 0C 65 C2 E4
------------------------------------------------------------------

	

Date: Mon, 14 Apr 1997 18:54:54 -0700
To: [email-masked]
From: "Paul E. Hoffman" <[email-masked]>
Subject: Minutes from Memphis, edited version, first draft
Sender: [email-masked]

Greetings again. Many thanks to Laurence for his minutes of the IETF
Memphis meeting. I also received input from other people, and have combined
them into the following. Please feel free to comment on the minutes on this
mailing list. I'll submit the final version to the IETF next week.

Second S/MIME BOF Meeting Minutes
38th IETF, Memphis April 8, 1997

Minutes taken by Laurence Lundblade,
edited and revised by Paul Hoffman

Chairs:
Paul Hoffman and Blake Ramsdell

Agenda:
Introduction
Status of Drafts
Status of S/MIME products
Working group formation
Issues with current draft

Mailing lists:
[email-masked] - for discussion of the drafts
[email-masked] - for discussion of developer issues

A question was raised as to whether work on the secuity multiparts
MIME standard would be pulled into this Working Group. The problem
raised was that they require exact bit integrity for the signature to
remain valid, and this is particularly a problem with the
multipart/related MIME type. It was decided that this work was out of
scope for the S/MIME group, but should be persued elsewhere.

Mention was made that the charter was posted to the mailing lists
after the previous BOF and resulted in little response.

Status of Drafts:
Two drafts were submitted to the IETF. One is a combination of the
previous S/MIME message specification and the interoperability guide.
The other is a certificate specification that was split out from the
previous documents.  Each draft lists open issues. The drafts are
available at <http://www.imc.org/ietf-smime/>.

Products status:
Shipping: Entrust, ConnectSoft, Deming/WorldTalk, Frontier, OpenSoft
Near Shipping: Netscape Messenger, Internet Explorer 4 (Microsoft)

Discussion about forming a Working Group:

Paul Hoffman started by stating that a working group will result in
better publicity in the IETF, better interaction with other IETF work,
and greater vendor confidence. However, he tried to form the WG three
months ago with little response to the proposed charter.

Jeff Schiller, the IESG area director for security, responded that the
purpose of a WG is to make a standard, not to get publicity. This BOF
must focus on standards work and make a decision. A charter must say
the working group desires to create a standard because working groups
are only for creating standards. There cannot be another BOF (you only
get two, and this is the second).

Also, RSA needs to relinquish change control for the work to become a
standard. Vendors must follow what this WG does, or there is no point
to creating this WG.

Tim Matthews from RSA said the main reason for control over the S/MIME
name was to gaurantee interoperability between implementations that
are labeled S/MIME, but would be willing to turn over control of the
name if interoperability was otherwise gauranteed.

The current document requires intellectual property rights (IPR) of
RSA.

The reason RC2 was used is that it was cleared by the U.S. Commerce
Department for expedited export. It is very easy for a vendor to
export crypto with 40 bit RC2.

(Background note: RC2 is a trade secret of RSA. It is not patented.
Trade secrets last forever as long as they are protected, but it is
the responsibility of the owner to protect them. Some suggest the RC2
trade secret is gone. For example, there are at least two documents
available on the Internet that purport to describe the same algorithm,
or a fully interoperable algorithm, to RC2.)

The attendees were asked whether implementors in the room were willing
to give change control for the spec to the IETF. Many were willing.
Some reasons given for not forming a working group to produce a
standard (and leaving control with RSA) were that we might not be able
to get through the whole process, or that the result has some security
hole.

A point was made that the standard should be open on the issue of
algorithms <applause>.

A point was made that we can't do that with current algorithms (most
are encumbered with some sort of IPR).

A point was made that said that interoperability with current
implementations was OK, but that 40 bit crypto is unacceptably
insecure for some communities. This point was quickly countered that
the debate over the sufficiency of 40 bits was out of the scope of
this meeting.

Jeff Schiller suggested one solution that would be acceptable to him
(although this doesn't mean the IESG and IAB approve of it) is to have
a single profile that doesn't require RC2. A poll of the room showed
that many people thought this would be acceptable. When polled with
the inverse question (who would object to the IETF spec not requiring
RC2), no one objected.

A point was made that non-US implentors can implement technology that
is deemed not exportable in the US. There was a suggestion that we go
ahead without RC2. Some questioned whether or not this would be
"S/MIME".

Jeff Schiller said in no uncertain terms that the  S/MIME IPR issue must be
resolved by July 1, 1997 or working group could not be formed.
Tim Matthews from RSA said that RSA can work with that time frame.

Jeff also said:

- Interoperability is a must, therefore some algorithms must be
mandatory. He has a strong bias towards open algorithms, but can
accept some that are not.

- Control of the spec must be completely with in the IETF, e.g., IETF
"has a license to do S/MIME" and IETF says what the protocol is.

- PKCS7 isn't an issue. It can be published as an informational RFC.
The patents on the RSA algorithm are not an issue because they will
expire. Thus the issue is with the RC2 algorithm because it is a trade
secret which will never expire. RSA has not disavowed its IPR for RC2
and it could claim IPR for a long time.

- RSA must resolve two issues before a working group can begin work
towards a standard. RSA must decide what to do with the name "S/MIME".
Also, S/MIME must not rely on a trade secret; RSA could say that RC2
was no longer a trade secret.

Other issues:

Laurence Lundblade presented proposal for reorganization of Section 3
of the message document. The reorganization was for the sake of
clarity and to separate the definition of the message formats from the
rationale for their use. There was general agreement towards the
proposal.

Other open issues were going to be addressed, but the meeting started
to break up. We decided to take the rest of the discussion to the
mailing list.

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

Date: Mon, 14 Apr 1997 19:11:36 -0700
To: [email-masked]
From: "Paul E. Hoffman" <[email-masked]>
Subject: Keeping the mailing lists separate (ietf-smime edition)
Sender: [email-masked]

Greetings, S/MIME spec workers. As you probably know, there are two mailing
lists that relate to S/MIME. There is this list ([email-masked]), which
is for developers implementing S/MIME, and there is anotherh list
([email-masked]) for discussing the S/MIME specification work that is
going on in the IETF. These two efforts, even though they are being done by
mostly the same people, are quite different.

The RSA folks and many of their developers are helping support the IETF
work, so this is defintely not an "us vs. them" situation. It's "both/and",
not "either/or".

Please do *not* cross-post to the two mailing lists. There is a long
history on the Internet of discussions that happen on two lists at once
falling apart as some people only reply to one list. Given that these two
efforts are fairly easily defined, and both lists are open to anyone, there
is no reason to cross-post, and plenty of reason not to.

Discussion such as "how do I implement abc", "who has implemented def",
"are there any toolkits for ghi", and so on belong on *the other* list.
Discussion such as "should S/MIME have jkl", "will the mno feature go into
the next round of S/MIME", and "I think that the pqr feature is
unnecessary" should go on *this* list.

Again, it is quite alright to be on both lists. In fact, I imagine that any
S/MIME developer would care about the IETF work, and would therefore want
to be on both lists, even if they only lurk. Similarly, many people working
on the S/MIME spec in the IETF would probably care about how the developers
are doing. I promise to post occaisional messages here to alert people
about implementation issues that come up on the other list that affect the
IETF work.

To get on the the smime-dev mailing list, send mail to:
     [email-masked]
with the message
     subscribe smime-dev

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

Date: Mon, 14 Apr 1997 18:52:53 -0700
To: [email-masked]
From: "Paul E. Hoffman" <[email-masked]>
Subject: Proposed charter, second round
Sender: [email-masked]

In order to become a working group, we need general agreement on a charter.
I propose the following, which is a revision of the one I proposed in
February.

Description of the Working Group:

S/MIME is a method for encrypting and/or authenticating MIME data.
S/MIME defines a format for the MIME data, the algorithms that must be
used for interoperability, and the additional operational concerns
such as certificates and transport over the Internet.

Work on S/MIME has already begun before the formation of this Working
Group. This WG will use as a starting point the two drafts already
submitted to the IETF for S/MIME. These drafts are based on the PKCS7
message format. The Working Group will most likely maintain
interoperability with the message format from the current S/MIME work.

A modestly aggressive schedule is specified, due to the amount of existing
work on S/MIME.

Goals and Milestones:

March 1997: Submit first drafts of S/MIME message specification
     and S/MIME certificate handling

July 1997: WG last call on S/MIME message specification

July 1997: Submit all reformatted PKCS documents as Informational

August 1997: Submit S/MIME message specification for Proposed
     Standard

September 1997: WG last call on S/MIME certificate handling

October 1997: Submit S/MIME certificate handling for Proposed
     Standard

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

From: Steve Dusse <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Charles Breed'" <[email-masked]>
Subject: RE: 2nd S/MIME BOF meeting minutes
Date: Mon, 14 Apr 1997 11:45:24 -0700
Sender: [email-masked]

Hi Charles,
>
>5. The spec should allow for handling of additional certificate types, such
>as the SPKI (SDSI) working group proposed data structure.
>
I'm not as up on SPKI as I should be.  Does SPKI use some mechanism
other than an X.509 certificate for conveying trust ?

-steve
>
>
>
>
>
>
>At 01:24 PM 4/12/97 -0700, Laurence Lundblade wrote:
>>Second S/MIME BOF Meeting Minutes
>>38th IETF, Memphis
>>April 8, 1997
>>
>>Chairperson: Paul Hoffman
>>
>>Agenda:
>>  Introduction
>>  Status of Drafts
>>  Status of S/MIME products
>>  Working group formation
>>  Issues with current draft
>>
>>Mailing lists:
>>  [email-masked] - for discussion of the drafts
>>  [email-masked] - for discussion of developer issues
>>
>>A couple of issues were brought up before we got started on the Agenda:
>>  A question was raised as to whether work on the secuity multiparts
>>standard
>>  would be pulled into this working group. The problem raised was that they
>>  require exact bit integrity for the signature to remain valid, and this is
>>  particularly a problem with the multipart/related MIME type.
>>
>>  Mention was made that the charter was posted to the mailing lists after
>>the
>>  previous BOF and resulted in little response
>>
>>
>>Status of Drafts (Paul Hofman):
>>  Two drafts were submitted to the IETF. One is a combination of the
>>previous S/MIME
>>  message specification and the interoperability guide. The other is a
>>certificate
>>  specification that was split out from the previous documents.  Each draft
>>lists open
>>  issues.
>>
>>
>>Products status (Blake Ramsdel):
>>  Shipping: Entrust, ConnectSoft, Deming/WorldTalk, Frontier, OpenSoft
>>  Near Shipping: Netscape Messenger, Internet Explorer 4 (Microsoft)
>>
>>
>>Working group (these notes are cronological; the discussion was chaotic):
>>  Intro slide shows:
>>    - A working group will result in better publicity in the IETF
>>    - Better interaction with IETF
>>    - Greater vendor confidence
>>    - tried to form 3 mo. ago with little response (to charter)
>>
>> Jeff Schiller, security area director, responds:
>>     Purpose is to make a standard, not to get publicity. This BOF must
>>focus and make
>>     a decision. A charter must say the working group desires to create a
>>standard because
>>     working groups are only for creating standards. There cannot be
>>another BOF.
>>
>>     Also, RSA needs to relinquish change control
>>
>>  Other issues brought up (chronological order):
>>     Vendors must follow what this working group does, or there is no point
>>in having
>>     this working group.
>>
>>     Tim Matthews of RSA said the main reason for control over the S/MIME
>>name was to
>>     gaurantee interoperability between implementations that are labeled
>>S/MIME,
>>     but would be willing to turn over control of the name if
>>interoperability was
>>     otherwise gauranteed
>>
>>     The current document requires intellectual property rights (IPR) of
>>RSA.
>>
>>     The reason RC2 is used is because it has been cleared by the commerce
>>department
>>     for export. It is very easy for a vendor to export crypto with 40 bit
>>RC2. No other
>>     algorithm has the same support (yet).
>>
>>     (editors note - RC2 is a trade secret of RSA. It is not patented.
>>Trade secrets are
>>       indefinite as long as they are protected, but it is the
>>responsibility of the owner
>>       to protect them)
>>
>>     Some suggest the RC2 trade secret is gone
>>
>>     A poll asked whether implementors were willing to give change control
>>to the IETF.
>>     Many were willing. Some reasons given for not forming a working group
>>to produce a
>>     standard (and leaving control with RSA) were that we can't get through
>>the process, or
>>     that the result has some security hole.
>>
>>     The process should not be a rubber stamp process.
>>
>>     A point was made that the standard should be open on the issue of
>>algorithms <applause>.
>>
>>     A point was made that we can't do that with current algorithms (most
>>are encumbered).
>>
>>     A point was made that acknowledged that interoperability with current
>>implementations
>>    was OK, but that 40 bit crypto is unacceptably insecure for some
>>communities. This
>>    point was quickly countered that the debate over the sufficiency of 40
>>bits was out of the
>>    scope of this meeting.
>>
>>    We have several choices
>>      - S/MIME evolves to be non-proprietary (e.g. stops requiring
>>proprietary algs)
>>      - The right to algorithms it uses are released
>>      - Do something completely different (e.g., MOSS)
>>    Both profiles in S/MIME currently require RC2 (proprietary)
>>    There is a similar problem with TLS
>>
>>    Jeff suggests one solution that would be acceptable to him (which
>>doesn't mean the IESG and
>>    IAB approve (yet)) is to have a single profile that doesn't include
>>RC2, 40 bits.
>>
>>    A poll showed this would be acceptable and there was no decension (RSA
>>representive obstains)
>>
>>    A point was made that non-US implentors can implement technology that
>>is deemed not
>>    exportable in the US.
>>
>>    Suggestion that we go ahead without RC2.... Some questioned whether or
>>not this would
>>    be "S/MIME".
>>
>>   (editor: now we're getting to the nitty gritty...)
>>
>>    Jeff (area directory): S/MIME IPR issue must be resolved by July 1,
>>1997 or working group
>>    cannot be formed
>>
>>    Tim (RSA Inc.): RSA can work with that time frame
>>
>>    Jeff's requirements:
>>      Interoperability is a requirement, therefore some algorithms must be
>>mandatory. Have a
>>      strong bias towards open algorithms, but can accept some that are
>>not. There are open
>>      symmetric algorithms (editor: that can be used instead of RC2)
>>
>>      Control must be with in the IETF, e.g., IETF "has a license to do
>>S/MIME" and IETF says what
>>      the protocol is.
>>
>>      PKCS7 isn't an issue. It can be published as an informational RFC.
>>
>>      The patents on the RSA algorithm are not an issue because they will
>>expire. Thus the
>>      issue is with the RC2 algorithm because it is a trade secret which
>>will never expire.
>>      RSA has not disavowed its IPR for RC2 and it could go on for a long
>>time.
>>
>>(editor's summary: RSA must resolve two issues before a working group can
>>begin work
>> towards a standard. 1) S/MIME must not rely on a trade secret (RC2), 2)
>>Change control
>> must be with the IETF (e.g., the rights to the "S/MIME" trademark must be
>>neutrally held.)
>> These must be resolved by July 1, 1997.  The RSA representive acknowledged
>>this).
>>
>>
>>
>>On to issues (with a few minutes left)
>>  Laurence presented proposal for reorganization of section 3 of the
>>document. The reorganization
>>  was for the sake of clarity and to separate the definition of the message
>>formats from the rationale
>>  for their use. There was general ascent towards the proposal, though the
>>meeting began to break up.
>>
>>  At this point we gave up the meeting was breaking up
>>
>>  One last issue raised - does the inside object really have to be MIME
>>encoded or not (editor it
>>  wasn't clear whether this was the issue of transfer encoding or the issue
>>of MIME vs 822).
>>
>>
>>
>>
>>
>

Date: Mon, 14 Apr 1997 11:17:50 -0700
To: Laurence Lundblade <[email-masked]>, [email-masked], [email-masked]
From: Charles Breed <[email-masked]>
Subject: Re: 2nd S/MIME BOF meeting minutes
Sender: [email-masked]

	(The meeting was on April 9th, not the 8th...)

The issues brought up by the IETF Security Area Director, Jeff Schiller, were inevitable. S/MIME needs to exist with open, non-proprietary profiles as well as profile that require licensing of patented algorithms, especially if one wants an elliptic curve algorithm.

I propose the following changes to move this forward as a working group...

1. RSA to give the 'S/MIME' trade mark to a neutral, non-profit organization that's willing to arbitrate interoperability disputes. (or change the name of the spec)

2. The only MUST profile should be RSA (Public Key), 3DES (Symmetric), SHA-1 (Message Digest)

3. Unfortunately, the MUST profile (for interoperability), will be US export controlled. US export requirements should NOT be imposed upon an international standards organization. (Why should someone in Japan be forced to uses 40-bit weak crypto to communicate with someone in Germany, if their profile is unknown?) It is more dangerous to resort to weak crypto than nothing at all. Some folks would want to be able to state, "Do not send me anything less than 128-bit".

4. PKCS #7 to be an informational rfc prior to S/MIME final call

5. The spec should allow for handling of additional certificate types, such as the SPKI (SDSI) working group proposed data structure.

regards,
Charles Breed

At 01:24 PM 4/12/97 -0700, Laurence Lundblade wrote:
>Second S/MIME BOF Meeting Minutes
>38th IETF, Memphis
>April 8, 1997
>
>Chairperson: Paul Hoffman
>
>Agenda:
>  Introduction
>  Status of Drafts
>  Status of S/MIME products
>  Working group formation
>  Issues with current draft
>
>Mailing lists:
>  [email-masked] - for discussion of the drafts
>  [email-masked] - for discussion of developer issues
>
>A couple of issues were brought up before we got started on the Agenda:
>  A question was raised as to whether work on the secuity multiparts standard
>  would be pulled into this working group. The problem raised was that they
>  require exact bit integrity for the signature to remain valid, and this is
>  particularly a problem with the multipart/related MIME type.
>
>  Mention was made that the charter was posted to the mailing lists after the
>  previous BOF and resulted in little response
>
>
>Status of Drafts (Paul Hofman):
>  Two drafts were submitted to the IETF. One is a combination of the
>previous S/MIME
>  message specification and the interoperability guide. The other is a
>certificate
>  specification that was split out from the previous documents.  Each draft
>lists open
>  issues.
>
>
>Products status (Blake Ramsdel):
>  Shipping: Entrust, ConnectSoft, Deming/WorldTalk, Frontier, OpenSoft
>  Near Shipping: Netscape Messenger, Internet Explorer 4 (Microsoft)
>
>
>Working group (these notes are cronological; the discussion was chaotic):
>  Intro slide shows:
>    - A working group will result in better publicity in the IETF
>    - Better interaction with IETF
>    - Greater vendor confidence
>    - tried to form 3 mo. ago with little response (to charter)
>
> Jeff Schiller, security area director, responds:
>     Purpose is to make a standard, not to get publicity. This BOF must
>focus and make
>     a decision. A charter must say the working group desires to create a
>standard because
>     working groups are only for creating standards. There cannot be
>another BOF.
>
>     Also, RSA needs to relinquish change control
>
>  Other issues brought up (chronological order):
>     Vendors must follow what this working group does, or there is no point
>in having
>     this working group.
>
>     Tim Matthews of RSA said the main reason for control over the S/MIME
>name was to
>     gaurantee interoperability between implementations that are labeled
>S/MIME,
>     but would be willing to turn over control of the name if
>interoperability was
>     otherwise gauranteed
>
>     The current document requires intellectual property rights (IPR) of RSA.
>
>     The reason RC2 is used is because it has been cleared by the commerce
>department
>     for export. It is very easy for a vendor to export crypto with 40 bit
>RC2. No other
>     algorithm has the same support (yet).
>
>     (editors note - RC2 is a trade secret of RSA. It is not patented.
>Trade secrets are
>       indefinite as long as they are protected, but it is the
>responsibility of the owner
>       to protect them)
>
>     Some suggest the RC2 trade secret is gone
>
>     A poll asked whether implementors were willing to give change control
>to the IETF.
>     Many were willing. Some reasons given for not forming a working group
>to produce a
>     standard (and leaving control with RSA) were that we can't get through
>the process, or
>     that the result has some security hole.
>
>     The process should not be a rubber stamp process.
>
>     A point was made that the standard should be open on the issue of
>algorithms <applause>.
>
>     A point was made that we can't do that with current algorithms (most
>are encumbered).
>
>     A point was made that acknowledged that interoperability with current
>implementations
>    was OK, but that 40 bit crypto is unacceptably insecure for some
>communities. This
>    point was quickly countered that the debate over the sufficiency of 40
>bits was out of the
>    scope of this meeting.
>
>    We have several choices
>      - S/MIME evolves to be non-proprietary (e.g. stops requiring
>proprietary algs)
>      - The right to algorithms it uses are released
>      - Do something completely different (e.g., MOSS)
>    Both profiles in S/MIME currently require RC2 (proprietary)
>    There is a similar problem with TLS
>
>    Jeff suggests one solution that would be acceptable to him (which
>doesn't mean the IESG and
>    IAB approve (yet)) is to have a single profile that doesn't include
>RC2, 40 bits.
>
>    A poll showed this would be acceptable and there was no decension (RSA
>representive obstains)
>
>    A point was made that non-US implentors can implement technology that
>is deemed not
>    exportable in the US.
>
>    Suggestion that we go ahead without RC2.... Some questioned whether or
>not this would
>    be "S/MIME".
>
>   (editor: now we're getting to the nitty gritty...)
>
>    Jeff (area directory): S/MIME IPR issue must be resolved by July 1,
>1997 or working group
>    cannot be formed
>
>    Tim (RSA Inc.): RSA can work with that time frame
>
>    Jeff's requirements:
>      Interoperability is a requirement, therefore some algorithms must be
>mandatory. Have a
>      strong bias towards open algorithms, but can accept some that are
>not. There are open
>      symmetric algorithms (editor: that can be used instead of RC2)
>
>      Control must be with in the IETF, e.g., IETF "has a license to do
>S/MIME" and IETF says what
>      the protocol is.
>
>      PKCS7 isn't an issue. It can be published as an informational RFC.
>
>      The patents on the RSA algorithm are not an issue because they will
>expire. Thus the
>      issue is with the RC2 algorithm because it is a trade secret which
>will never expire.
>      RSA has not disavowed its IPR for RC2 and it could go on for a long time.
>
>(editor's summary: RSA must resolve two issues before a working group can
>begin work
> towards a standard. 1) S/MIME must not rely on a trade secret (RC2), 2)
>Change control
> must be with the IETF (e.g., the rights to the "S/MIME" trademark must be
>neutrally held.)
> These must be resolved by July 1, 1997.  The RSA representive acknowledged
>this).
>
>
>
>On to issues (with a few minutes left)
>  Laurence presented proposal for reorganization of section 3 of the
>document. The reorganization
>  was for the sake of clarity and to separate the definition of the message
>formats from the rationale
>  for their use. There was general ascent towards the proposal, though the
>meeting began to break up.
>
>  At this point we gave up the meeting was breaking up
>
>  One last issue raised - does the inside object really have to be MIME
>encoded or not (editor it
>  wasn't clear whether this was the issue of transfer encoding or the issue
>of MIME vs 822).
>
>
>
>
>

Date: Sat, 12 Apr 1997 13:24:01 -0700
To: [email-masked], [email-masked]
From: Laurence Lundblade <[email-masked]>
Subject: 2nd S/MIME BOF meeting minutes
Sender: [email-masked]

Second S/MIME BOF Meeting Minutes
38th IETF, Memphis
April 8, 1997

Chairperson: Paul Hoffman

Agenda:
  Introduction
  Status of Drafts
  Status of S/MIME products
  Working group formation
  Issues with current draft

Mailing lists:
  [email-masked] - for discussion of the drafts
  [email-masked] - for discussion of developer issues

A couple of issues were brought up before we got started on the Agenda:
  A question was raised as to whether work on the secuity multiparts standard
  would be pulled into this working group. The problem raised was that they
  require exact bit integrity for the signature to remain valid, and this is
  particularly a problem with the multipart/related MIME type.

  Mention was made that the charter was posted to the mailing lists after the
  previous BOF and resulted in little response

Status of Drafts (Paul Hofman):
  Two drafts were submitted to the IETF. One is a combination of the
previous S/MIME
  message specification and the interoperability guide. The other is a
certificate
  specification that was split out from the previous documents.  Each draft
lists open
  issues.

Products status (Blake Ramsdel):
  Shipping: Entrust, ConnectSoft, Deming/WorldTalk, Frontier, OpenSoft
  Near Shipping: Netscape Messenger, Internet Explorer 4 (Microsoft)

Working group (these notes are cronological; the discussion was chaotic):
  Intro slide shows:
    - A working group will result in better publicity in the IETF
    - Better interaction with IETF
    - Greater vendor confidence
    - tried to form 3 mo. ago with little response (to charter)

 Jeff Schiller, security area director, responds:
     Purpose is to make a standard, not to get publicity. This BOF must
focus and make
     a decision. A charter must say the working group desires to create a
standard because
     working groups are only for creating standards. There cannot be
another BOF.

     Also, RSA needs to relinquish change control

  Other issues brought up (chronological order):
     Vendors must follow what this working group does, or there is no point
in having
     this working group.

     Tim Matthews of RSA said the main reason for control over the S/MIME
name was to
     gaurantee interoperability between implementations that are labeled
S/MIME,
     but would be willing to turn over control of the name if
interoperability was
     otherwise gauranteed

     The current document requires intellectual property rights (IPR) of RSA.

     The reason RC2 is used is because it has been cleared by the commerce
department
     for export. It is very easy for a vendor to export crypto with 40 bit
RC2. No other
     algorithm has the same support (yet).

     (editors note - RC2 is a trade secret of RSA. It is not patented.
Trade secrets are
       indefinite as long as they are protected, but it is the
responsibility of the owner
       to protect them)

     Some suggest the RC2 trade secret is gone

     A poll asked whether implementors were willing to give change control
to the IETF.
     Many were willing. Some reasons given for not forming a working group
to produce a
     standard (and leaving control with RSA) were that we can't get through
the process, or
     that the result has some security hole.

     The process should not be a rubber stamp process.

     A point was made that the standard should be open on the issue of
algorithms <applause>.

     A point was made that we can't do that with current algorithms (most
are encumbered).

     A point was made that acknowledged that interoperability with current
implementations
    was OK, but that 40 bit crypto is unacceptably insecure for some
communities. This
    point was quickly countered that the debate over the sufficiency of 40
bits was out of the
    scope of this meeting.

    We have several choices
      - S/MIME evolves to be non-proprietary (e.g. stops requiring
proprietary algs)
      - The right to algorithms it uses are released
      - Do something completely different (e.g., MOSS)
    Both profiles in S/MIME currently require RC2 (proprietary)
    There is a similar problem with TLS

    Jeff suggests one solution that would be acceptable to him (which
doesn't mean the IESG and
    IAB approve (yet)) is to have a single profile that doesn't include
RC2, 40 bits.

    A poll showed this would be acceptable and there was no decension (RSA
representive obstains)

    A point was made that non-US implentors can implement technology that
is deemed not
    exportable in the US.

    Suggestion that we go ahead without RC2.... Some questioned whether or
not this would
    be "S/MIME".

   (editor: now we're getting to the nitty gritty...)

    Jeff (area directory): S/MIME IPR issue must be resolved by July 1,
1997 or working group
    cannot be formed

    Tim (RSA Inc.): RSA can work with that time frame

    Jeff's requirements:
      Interoperability is a requirement, therefore some algorithms must be
mandatory. Have a
      strong bias towards open algorithms, but can accept some that are
not. There are open
      symmetric algorithms (editor: that can be used instead of RC2)

      Control must be with in the IETF, e.g., IETF "has a license to do
S/MIME" and IETF says what
      the protocol is.

      PKCS7 isn't an issue. It can be published as an informational RFC.

      The patents on the RSA algorithm are not an issue because they will
expire. Thus the
      issue is with the RC2 algorithm because it is a trade secret which
will never expire.
      RSA has not disavowed its IPR for RC2 and it could go on for a long time.

(editor's summary: RSA must resolve two issues before a working group can
begin work
 towards a standard. 1) S/MIME must not rely on a trade secret (RC2), 2)
Change control
 must be with the IETF (e.g., the rights to the "S/MIME" trademark must be
neutrally held.)
 These must be resolved by July 1, 1997.  The RSA representive acknowledged
this).

On to issues (with a few minutes left)
  Laurence presented proposal for reorganization of section 3 of the
document. The reorganization
  was for the sake of clarity and to separate the definition of the message
formats from the rationale
  for their use. There was general ascent towards the proposal, though the
meeting began to break up.

  At this point we gave up the meeting was breaking up

  One last issue raised - does the inside object really have to be MIME
encoded or not (editor it
  wasn't clear whether this was the issue of transfer encoding or the issue
of MIME vs 822).