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