ietf-smime
[Top] [All Lists]

Re: 2nd S/MIME BOF meeting minutes

1997-04-14 11:13:20
        (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).