(Note: subject line restored - it got chopped because I misspelled it as "subect" and used raw sendmail. Also, the original text, with small corrections, is available at http://www.c2.org/~raph/report.html) On Fri, 23 Feb 1996, Brad Knowles wrote:
At 4:55 PM 2/22/96, Raph Levien wrote:
The biggest problem with S/MIME is that the signed and encrypted format reveals who made the signatures. Obviously, this has severe consequences for anonymous mail. Believe it or not, a lot of people care.
IMO, this has to be fixed as well. The good thing is that the folks who have an investment in S/MIME seem to be willing to make changes to the specification to suit the desires of the larger secure Internet email connunity at large. I hope that companies like VeriSign (that help other comapnies to implement this kind of technology) also agree to follow suit.
This can be fixed as easily as allowing the protected MIME part to be an S/MIME signed message. The S/MIME spec will need to recommend that mailers deal gracefully with this case; if not, there will be user interface disasters. I'd recommend that mail readers treat recursive encrypted and signed S/MIME messages identically to non-recursive (i.e. PKCS #7 native). Even better would be for the RSA's S/MIME toolkit to be able to perform the translation automatically. I agree with Brad that it needs to be fixed. If a large installed base of S/MIME clients gets deployed that cannot handle the S/MIME format hiding the signatory, then we will have failed in an important way.
One strength of PGP has traditionally been its unity. PGP means one message format (the PGP one), one suite of crypto algorithms (the PGP one), one key format (the PGP one), one application (PGP itself). Most of the other proposals are modular in some way, especially with respect to algorithms. PGP is moving in that direction.
IMO, unity in this case is both a benefit and a deficit. Because it has not historically been separable, it's either all or none of PGP, and that's not an implementory style that's likely to win friends or marketshare. To that degree, I think PGP has probably been less successful than it could have been. To the degree that this is changing is one indicator of its potential to continue to be a player.
Agreed. The changes to PGP could be good, bad, or some combination. My real point is that whatever the reasons have been for PGP's success or failure, they won't resemble much the reasons why PGP will succeed or fail in the future.
Earlier, I mentioned that two and a half protocols survived the day. The remaining one is MSP. It's actually not a bad protocol. It has two features that none of the others have: the ability to label classified messages, and a cryptographically strong signed receipt. Both of these functions are highly important for government users. It looks like government suppliers are going to go ahead and implement it, and the government is going to use it.
Although these benefits are present in the current MSP, I don't see anything inherent in MSP that makes it necessarily superior in these areas. If you were doing normal MIME-type receipts (whatever that means, since I think there are three different drafts under way currently), and you simply added the ability to cryptographically sign a timestamp in the "proper" MIME receipt type, then MSP would lose this advantage.
I think labeling could potentially be done by follow-on versions of other packages as well, since I think we all agree that generic labeling which can be used both for standard gov't-style classification levels and compartments, as well as for business-style sensitivity labeling. In fact, I'd almost be inclined to say that it would likely be as easy (or easier) to create a new general-purpose labeling system for use with any of the competitors than it would be to modify MSP to support business-style labels in addition to the gov't-style labels I'm sure it has today (maybe it already has labels, but I don't think that this is that tough of a problem to solve in any event).
One of the action items from the conference was for the contenders to converge on any pieces that were not gratuitously different. For S/MIME and PGP/MIME to simply adopt receipt and labelling standards, even to lift them wholesale from MSP, would be well in accordance with this goal, I think.
This is where I say that what we need to do is neither cave in to the limitation imposed by the gov't nor do we accept that we have to rip out encryption from our products to be shipped overseas or used in the U.S. on the behalf of overseas customers. We need to (on a daily basis) wipe the gov't nose in this mess that they've created, until such time as they learn that it stinks and that they shouldn't do that indoors anymore.
ITAR be damned.
Hear, hear. My point is that it isn't just cypherpunk advocacy of strong crypto. Any company that ships a 40-bit product is going to get badly burned by well publicized breaks. Their customers are going to feel betrayed. They thought they were buying a "secure" solution, but they weren't. Perhaps this is putting it a bit strongly, but using the word "secure" in conjunction with a 40-bit produce borders on fraud. Perhaps it makes more business sense to defend against the ITAR on First Amendment grounds than to defend against fraud charges on ITAR grounds. If not a lawsuit, then a disillusioned customer base, which is just as bad.
If care about offering crypto in the non-US market, form a partnership with overseas developers to add the crypto.
Non-US developers, now is a fabulous opportunity. Get those implementations underway, the sooner the better.
And own the crown jewels to every single company in the U.S. all that much faster. It's not like the NSA is help to protect them from espionage that originates from competitors or from what used to be the political espionage organizations that are now fighting to keep their jobs. It's not like companies will have a single moments interest in having to deal with two different standards for their U.S. customers and overseas customers, or worse, their U.S. subsidiaries and their overseas subsidiaries.
Everybody should buy their encryption technology from a country where this kind of thing isn't under export control, and then ship (or operate) from that country. When all the companies have moved overseas somewhere (or at least moved the official bits that they have to move in order to make this happen), maybe the U.S. gov't will wake up. But of course, by then it will be too late. And the NSA (and other governmental entities) will have succeeded in doing "Very Grave Harm to National Security Interests" because there won't be much of a Nation left behind when all the companies (and therefore workers) are overseas.
Sorry, this has been a *major* sore point with me for years.
Most serious email vendors plan to "implement everything that's real." That means S/MIME for sure, PGP/MIME assuming they can get their hands on a decent implementation, and MSP if they sell a lot of stuff to the government.
I'm hoping that we'll be able to significantly reduce the playing field of "what's real".
I think we just did. The only other way for the field to reduce any more is for PGP to tank (unlikely), for RSA to drop S/MIME (unlikely) or for MSP to disappear (won't happen entirely - witness X.400).
Over the next few months, we will see some very high profile, mass market implementations.
You may see them from others, but I don't think you're likely to see them from us anytime soon. See my comments above about ITAR. We're a world-wide company (and trying to become even moreso) with world-wide customers. Hell, we could even get completely cut off from certain countries because they deem that we're providing access to "illegal" or "unapproved" encryption technologies.
I was speaking about others ;-). A lot of people have announced that they're going to implement S/MIME. The remaining question is whether they're really going to do so. Without sticking out my neck and naming individual companies, the impression I got is that they are.
At the end of the meeting, Dave asked the room for consensus on several points. First, there was strong consensus that the encryption protocols converge on multipart/security for their signed message format.
You mean "multipart/signed", right?
Yes.
There was also strong support for changing the "octet-stream" definition of "multipart/encrypted" to something more meaningful (hopefully simply state that it's one of the standard MIME types, and can presumably be safely converted to and from things like base64 or quoted-printable, or that its canonical form is one of the seven-bit safe formats). With that change, there was strong support that I heard voiced for supporting "multipart/encrypted" as well.
There was support, but was there consensus? My brain is just too fuzzy to remember.
I'd say that's quite a remarkable achievement for a such a difficult area.
Agreed. I think Dave Crocker deserves a lot of credit for how well he managed to shepard us "cats" and that he didn't let things get far enough off-track that we turned into "hostile cats".
Absolutely. Raph