Once again, I've been on the road, and this time out of RadioMail range, so I'm a bit behind on my mail again. I hope that my replies aren't too redundant with other things that have already been said on the mailing list(s), but I can't check without delaying my answer even longer, because my poor RadioMail service is now so backlogged that it may take a few days just for it to download everything... At 11:17 AM 12/21/94 -0800, Eric Hughes wrote:

The perceived need for crypto "below the line" comes from the viewpoint that the system needs to be completely secure because crypto failures must be prevented at all cost. Rubbish. The subsequent claim that you couldn't possibly put crypto on the Unix boxes which are in your control is therefore also bogus.

This is interesting; that was not the way I saw it, but I can see your point of view. From my end, I don't believe in "completely secure" as a reasonable goal for ANYthing, so this certainly wasn't what I intended to hold out for. Rather, my perspective is that if you add crypto, you should be getting something for it. It's easy to see how you get privacy benefits above the line, and if you do it right you might be able to get some security benefits too (though I haven't yet convinced myself of this). However, if we're going to be able to make some claims as to what we have added, I'd really like to be clear about them. What you've pointed out, that I hadn't thought of, is that if we put the crypto engine on the "above the line" system, we might get some significant and explainable benefits -- in particular, we gain protection of the user's privacy to the extent that breaking privacy now requires breaking into the above-the-line system, rather than merely snooping on the wire. This is true, and I thank you for pointing it out. I think I was a bit confused by the fact that I've thought of some really nice things that can be done when crypto is added BELOW the line, specifically related to the credit card information that ONLY lives there. What this means, however, is that there are now some useful things that can be done with crypto above the line, and even more that can be done with crypto below the line. If they were equally easy, it would make sense to add crypto below the line, as it would buy us more. However, as I've made very clear previously, it is NOT equally easy -- adding it above the line is much easier. This presents us with a new complication to the already complex tradeoffs involved in deciding where to devote our resources. I'm sure you'll understand if I'm reluctant to reach such an important decision overnight, but you've definitely opened my eyes to an attractive "middle path" in the use of optional cryptography in FV transactions. (On a technical level, the only thing I'd *really* like to wait for is the stabilization of the MIME-PGP work, as we'll need it in order to recognize a PGP-encrypted application/green-commerce MIME entity. As you know, I've been active in the MIME-PGP effort, and one very plausible scenario would be to make the FV server be an early implementation of that specification. However, the MIME-PGP draft that I co-wrote last summer is undergoing radical revision, so I'm reluctant to see that version implemented in our server.) In short, you've got a very good point, and you've probably just hastened the day when we support optional PGP encryption, but we're not ready to make any promises or timetables quite yet.

I really don't believe FV would have to put crypto on EDS equipment.

"Have to" is the key phrase here. You're absolutely right, and you've pointed out that there's real value in putting crypto on *our* equipment. The attitude I had previously expressed might have been an example of "the best is the enemy of the good" which is something I try to avoid. On the other hand, there are undeniable advantages to putting crypto on EDS equipment -- it's an interesting tradeoff.

The message that it's "not necessary for commerce" is reactionary to the assertation that it is necessary. By positioning FV in an adversarial role with respect to cryptography, you'll have the same problem no matter when you introduce crypto. I personally think you'll have a harder time changing your position later, after more people have been exposed to FV's current position.

A much better public position is that "you can do commerce with or without crypto", which asserts independence rather than negation. These two public positions are _not_ identical; they are similar, but don't be fooled by some positivist notion of denotation into thinking that they're the same.

This is another very important point. They may mean the same in some formal sense, which is what I believed, but your wording is MUCH more constructive. So let me state, with you, that I believe that you can do commerce with or without crypto, and that on the current Internet there are advantages and disadvantages to each approach. I suspect that we can further agree that privacy is one of the advantages of crypto-commerce, and that rapid deployment is one of the advantages of non-crypto-commerce. We may differ on some subtler aspects of that devil word, "security", but for the most part I think we're now in violent agreement. -- Nathaniel