Editor's Note: These minutes have not been edited.
Second S/MIME BOF Meeting Minutes
38th IETF, Memphis April 8, 1997
Minutes taken by Laurence Lundblade,
edited and revised by Paul Hoffman
Chairs:
Paul Hoffman and Blake Ramsdell
Agenda:
Introduction
Status of Drafts
Status of S/MIME products
Working group formation
Issues with current draft
Mailing lists:
ietf-smime@imc.org - for discussion of the drafts
smime-dev@rsa.com - for discussion of developer issues
A question was raised as to whether work on the secuity multiparts
MIME 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. It was decided that this work was out of
scope for the S/MIME group, but should be persued elsewhere.
Mention was made that the charter was posted to the mailing lists
after the previous BOF and resulted in little response.
Status of Drafts:
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. The drafts are
available at .
Products status:
Shipping: Entrust, ConnectSoft, Deming/WorldTalk, Frontier, OpenSoft
Near Shipping: Netscape Messenger, Internet Explorer 4 (Microsoft)
Discussion about forming a Working Group:
Paul Hoffman started by stating that a working group will result in
better publicity in the IETF, better interaction with other IETF work,
and greater vendor confidence. However, he tried to form the WG three
months ago with little response to the proposed charter.
Jeff Schiller, the IESG area director for security, responded that the
purpose of a WG is to make a standard, not to get publicity. This BOF
must focus on standards work 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 (you only
get two, and this is the second).
Also, RSA needs to relinquish change control for the work to become a
standard. Vendors must follow what this WG does, or there is no point
to creating this WG.
Tim Matthews from 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 was used is that it was cleared by the U.S. Commerce
Department for expedited export. It is very easy for a vendor to
export crypto with 40 bit RC2.
(Background note: RC2 is a trade secret of RSA. It is not patented.
Trade secrets last forever 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. For example, there are at least two documents
available on the Internet that purport to describe the same algorithm,
or a fully interoperable algorithm, to RC2.)
The attendees were asked whether implementors in the room were willing
to give change control for the spec 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 might not be able
to get through the whole process, or that the result has some security
hole.
A point was made that the standard should be open on the issue of
algorithms .
A point was made that we can't do that with current algorithms (most
are encumbered with some sort of IPR).
A point was made that said 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.
Jeff Schiller suggested one solution that would be acceptable to him
(although this doesn't mean the IESG and IAB approve of it) is to have
a single profile that doesn't require RC2. A poll of the room showed
that many people thought this would be acceptable. When polled with
the inverse question (who would object to the IETF spec not requiring
RC2), no one objected.
A point was made that non-US implentors can implement technology that
is deemed not exportable in the US. There was a suggestion that we go
ahead without RC2. Some questioned whether or not this would be
"S/MIME".
Jeff Schiller said in no uncertain terms that the S/MIME IPR issue must be
resolved by July 1, 1997 or working group could not be formed.
Tim Matthews from RSA said that RSA can work with that time frame.
Jeff also said:
- Interoperability is a must, therefore some algorithms must be
mandatory. He has a strong bias towards open algorithms, but can
accept some that are not.
- Control of the spec must be completely 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 claim IPR for a long time.
- RSA must resolve two issues before a working group can begin work
towards a standard. RSA must decide what to do with the name "S/MIME".
Also, S/MIME must not rely on a trade secret; RSA could say that RC2
was no longer a trade secret.
Other issues:
Laurence Lundblade presented proposal for reorganization of Section 3
of the message 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 agreement towards the
proposal.
Other open issues were going to be addressed, but the meeting started
to break up. We decided to take the rest of the discussion to the
mailing list.
--Paul E. Hoffman, Director
--Internet Mail Consortium