[Top] [All Lists]

2nd S/MIME BOF meeting minutes

1997-04-12 13:18:45
Second S/MIME BOF Meeting Minutes
38th IETF, Memphis
April 8, 1997

Chairperson: Paul Hoffman

  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
  specification that was split out from the previous documents.  Each draft
lists open

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
     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
     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
    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

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).

<Prev in Thread] Current Thread [Next in Thread>