[Top] [All Lists]

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

1997-04-15 11:42:25
     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 
     - 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 <spock(_at_)RSA(_dot_)COM> 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").
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 
    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 
profile that require licensing of patented algorithms, especially if one 
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 
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 
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 
the SPKI (SDSI) working group proposed data structure. 
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

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

    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 

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