Re: properties of FV

["NSB's Portable (via RadioMail)" <nsb@radiomail.net>]

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