[31] in WWW Security List Archive
Re: GSS API...
daemon@ATHENA.MIT.EDU (Jeff Hostetler)
Tue Aug 16 19:31:11 1994
From: jeff@spyglass.com (Jeff Hostetler)
To: "Roger Masse's the named" <rmasse@cnri.reston.va.us>
Cc: www-security@ns1.rutgers.edu, jeff@fido.spyglass.com
In-Reply-To: (Your message of Tue, 16 Aug 94 15:31:40 D.)
<9408161531.aa14041@CNRI.Reston.VA.US>
Date: Tue, 16 Aug 94 15:18:33 -0600
> I assume the server sends an encrypted copy of the requested
> document to the client to avoid unauthorized access to the
> document via a sniffing attack?
I'm not sure I understand what you mean here.
In the example, I'm assuming that the document is public-with-copyright
(as opposed to a document protected under a need-to-know policy) and
that the user is entitled to know of the document's existence and upon
payment (or proper kerberos-like authorization) entitled to a clear-text
copy of it.
For need-to-know documents, the server should 'lie' and
return a '404 Not Found'. The client must know (via an
out-of-band/off-line method) the address of an authorized
'authorization/payment service provider' and continue the
protocol at step 3.
> How do you protect the rights of the copyright holder enough to
> convince publishers to begin to use this method for dispursing intellectual
> property? There is more protection with hardcopy books. Sure I
> can give my bought-and-paid-for copy to someone else, but then I no
> longer have it. Or I could painstakingly rip appart the binding
> and copy the book for someone, but this is cumbersome... and time consuming
> and often the effort is not worth the value of the copy of the book.
> Put the book in electronic form, however, and copying is a snap
> once the client has decrypted their prize.
I'm not sure we can solve this problem within the security
protocol or within HTTP. At some point or anther, the user
has access to the clear-text (either we send it to them upon
payment or we send them encrypted-text and a key upon payment).
At that point the user is free to distribute it as desired.
--Unless we can convice browser vendors to build decryption
--into the client application AND disable CUT/COPY/SAVE/etc
--when viewing copyrighted materials. I don't look for this
--to happen.
Even if we timestamp or in some other manner uniquely mark
each paid-for copy of the document (to facilitate an after-the-fact
trace/audit), the user could still just edit the document and
rip it out.
I just don't see how we can get around this.
Sending the document encrypted might be nice to discourage
network snooping. I think this should be upto the discretion
of the 'a/p service provider' (do they care one way or another)
and the http server (do they have the cpu resources).
jeff
