Re:

At 4:55 PM 2/22/96, Raph Levien wrote:

One of the goals of the IMC is to involve users, not just developers. I was ready to "officially" represent the "cypherpunk user community," but fortunately, I didn't need to. In fact, the strongest advocacy of strong crypto came from an employee of a "large service provider in America."

I consider myself a neophyte CypherPunk, in that I just joined the DC CypherPunk mailing list. If you check a particular issue of _Communications of the ACM_ in the "ACM Forum" section, you'll see that I've been kicking around this kind of stuff for a little while. For anyone who is interested, I'll post or privately email the information on which issue it was, as soon as I can remember which issue it was.

There were five contenders on the field going into the day, and two and a half at the end. MOSS was one of the casualties. A lot of us were sorry to see it go, but eliminating candidates has got to happen if we're going to have interoperation.

I would have to say that MOSS does have the advantage of being very well MIME-integrated, and therefore can serve as a good framework on how to use something that is not necessarily PEM-based. I'm seriously hoping that whatever we finally come up with, it won't look too very different from RFC 1848, except where specific algorithms are discussed or perhaps additional features.

There was a lot of energy around S/MIME. People are implementing it. Internally, it's pretty kludgely, but it does provide pretty good cryptographic services. (as an aside, my favorite kludge anecdote is the fact that X.509 certificates use an IA5 character set rather than ASCII, so that the @ in email addresses has to be represented as (a) instead).

Oh, yeah. We (the community interested in secure Internet email) need to decide if we're willing to have an internal and an external representation differ in this manner, since we obviously can't show IA5 strings to the user or expect them to type in IA5 strings. My personal opinion is that the IA5 strings need to be dumped in favour of a proper Internet email address format (which I'm sure is specified by one of the bazillion email-related RFCs, I just don't know which one to reference).

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.

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.

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

My feeling is that the main differences are cultural. MSP still has a very ASN.1, OSI, governmental flavor. Its proponents are making the effort to be responsive to users, but I think there's still a bit of skepticism about that, perhaps misguided, perhaps not.

Yes, ASN.1. Ugh. Dave, have you been able to dig up that penultimate discourse upon ANS.1 from your brother? On the whole, I haven't read anything of MSP yet, so perhaps I'm totally off-base. Maybe I'm misguided on this, but when it comes to "new" protocols or standards that just suddenly drop onto my radar screen, I sometimes wonder why I haven't heard of them before and what someone is trying to hide.

My advice to US developers: don't even try to export a 40-bit version of your product. Just leave crypto out of the export version. Your product will have better performance and many fewer configuration problems. Include 40-bit in the US product if you have to, but don't allow it to be used silently. For example, put up a little dialog that says, "are you _sure_ you want to use 40-bit encryption? It's not secure, you know."

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.

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

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.

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

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". -Brad