Minutes of the Secure MIME (S/MIME) BOF
Reported by: Laurence Lundblade, Edited by Paul HoffmanAgenda
III. Status of S/MIME products
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 security 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 pursued elsewhere.
Mention was made that the charter was posted to the mailing lists after the previous BOF and resulted in little response.
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 <http://www.imc.org/ietf-smime/>.
Shipping: Entrust, ConnectSoft, Deming/WorldTalk, Frontier, OpenSoft
Near Shipping: Netscape Messenger, Internet Explorer 4 (Microsoft)
IV. Discussion about Forming a Working Group
Paul Hoffman began 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 Working Group three months ago with little response to the proposed charter.
Jeff Schiller, the IESG area director for security, responded that the purpose of a Working Group 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 Working Group does, or there is no point to creating this Working Group.
Tim Matthews from RSA said the main reason for control over the S/MIME name was to guarantee interoperability between implementations that are labeled S/MIME, but would be willing to turn over control of the name if interoperability is otherwise guaranteed.
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 <applause>.
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 implementors 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 clearly 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.
· Interoperability is necessary, 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 within 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.
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.