RE: Re[2]: 2nd S/MIME BOF meeting minutes

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:gaond(_at_)ncr(_dot_)disa(_dot_)mil]
> Sent:  Tuesday, April 15, 1997 10:13 AM
> To:    lgl(_at_)qualcomm(_dot_)com; ietf-smime(_at_)imc(_dot_)org; 
> smime-dev(_at_)RSA(_dot_)COM; 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 <cbreed(_at_)pgp(_dot_)com> 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:
> >  ietf-smime(_at_)imc(_dot_)org - for discussion of the drafts
> >  smime-dev(_at_)rsa(_dot_)com - 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).