(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
2. The only MUST profile should be RSA (Public Key), 3DES (Symmetric), SHA-1
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
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.
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
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
message specification and the interoperability guide. The other is a
specification that was split out from the previous documents. Each draft
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
working groups are only for creating standards. There cannot be
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
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
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
A point was made that we can't do that with current algorithms (most
A point was made that acknowledged that interoperability with current
was OK, but that 40 bit crypto is unacceptably insecure for some
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
- 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
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
(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
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
towards a standard. 1) S/MIME must not rely on a trade secret (RC2), 2)
must be with the IETF (e.g., the rights to the "S/MIME" trademark must be
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).