W3C home > Mailing lists > Public > www-talk@w3.org > March to April 1995

RE: trusted sources

From: Dan Connolly <connolly@w3.org>
Date: Tue, 4 Apr 1995 08:23:11 +0500
Message-Id: <9504041223.AA27270@www18.w3.org>
To: t-jont@microsoft.com
Cc: Multiple recipients of list <www-talk@www10.w3.org>
Jonathon Tidswell writes:
 > My initial reaction is it makes more sense for a new document type: 
 > signed-html.
 > The viewers for signed-html then worry about authentuicating the signature and
 > displaying proper messages etc.
 > I dont think a checksum is part of either a name (URN) or a location (URL).

So you only want signed html documents, huh? No signed postscript,
video, images, or Java class code?

Message integrity (knowing who the sender is, and knowing that no bit
has changed since it left the sender) and confidentiality (knowing
the possible recievers of a message) are very useful properties of
messages in network communications protocols, independent of the
format of the payload.

The PEM (privacy enhanced mail) extensions acknowledge this: they
allow you to enhance any message with confidentiality (encryption) and/or
integrity (signature).

Web security proposals (e.g. SSL and S-HTTP) acknowledge this as well:
SSL provides for an encrypted TCP connection. Encryption provides
integrity and confidentiality. S-HTTP allows HTTP messages to be
signed, encrypted, or both. A useful feature that web security
protocols should (and do?) provide is message integrity without a full
digital signature.

A digital signature introduces "non-repudiability," i.e. overwhelming
evidence that can be used at any time in the future to demonstrate
that the sender did in fact send the message. It's like a
receipt. When you're buying something, you might not want a
permanent record of your actions -- you might now want to get on
every mailing list in the country, for example.

So in many cases, it's useful (and cheaper, computationally) to
provide message integrity without signatures, for eample, by use of a
nonce, a shared secret, and a cryptographic hash.

Back to where the security information belongs... in order to traverse
a link securely (that is, in order to have mutual authentication), you
need to know the name of the party with whom you want to do secure
communication. This info must be in the link anchor, to make things
"as simple as they can be, but no simpler." I believe in SSL, the name
of the party is a function of the URL, i.e. it's the hostname in the
URL. In S-HTTP, there's an extra attribute, DN, that gives the
"distinguished name" of the party that you want to communicate with.

For more on the various technologies and proposals I've memtioned, see:

W3C Security Resource Page
Thu Mar 30 09:58:01 EST 1995

Hmmm... I'm not sure if that page is limited to consortium members
or not. I know the following one is not:

World Wide Web Security
$Date: 1995/03/29 22:09:45 $

Received on Tuesday, 4 April 1995 12:02:02 UTC

This archive was generated by hypermail 2.4.0 : Monday, 20 January 2020 16:08:16 UTC