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
