First some questions etc.

Harald Skardal (harald@ftp.com)
Tue, 07 Mar 95 14:47:52 EST

Scenarios taxonomy: Harald Skardal, March 7, 1995.

Before we start:
----------------
Before we get too bogged down in the details I think it is appropriate =
to
understand the scope and purpose of SHTTP, i.e:

Which are the parts of the problem that has to be reflected in SHTTP, =
and

Which parts of the problem should be handled outside SHTTP, i.e. by
protocol independent, and security method dependent code?

Before we try to partition each user application we need to understand =
where
we have to rely on components or solutions that are decided upon by the =

owner of the server or information, and delivered by the provider of the
security mechanism.
The following is an attempt to clearify, divide and concour, etc. I am =
not
so please comment if I am off the mark, unclear, etc.

Some fundamental questions:
---------------------------
1: Are public keys, as part of CA-certified certificates, distributed ahe=
ad
of the actual transaction of information? Or also, one downloaded an
encrypted document, should one then in a separate user operation acquire =

the key/certificate?
I would think that the key exchange is separate, this creates the same =

situation for private-public key based algorithms as for symmetric/secret=

keys. The question then is, how are these keys distributed? Do we need =
a
separate mechanism (within SHTTP) for key and certificate exchange?

2: Key Certification and distribution: is this the responsibility of the =

Web? It seems to me that we want the Web, i.e. SHTTP, to be independent =

from the actual seturity mechanism, i.e. RSA, PEM, DES, etc.. Therefore =

the issues related to whether we are using private-public, secret or othe=
r
key systems, and then how these are managed are outside the scope of
SHTTP. It is the owner of the =13to be protected=14 information that is =

responsible for setting up Certification Authorities etc. according to =

whether and how it is required by the security mechanism.
Implications:
SHTTP is really a protocol shell, and the SHTTP module in the server and =

client is really an extension registration and dispatching unit which
will encode or decode and verify signatures etc. according the specific
security method.
Key storage and access is the responsibility of the provider of the
security module, in line with the requirements of the actual mechanism.

3: To what extent should the reference implementation include
=13Light Security=14 which would be mechanically a full fledged system, =
but
using only short keys etc. to satisfy export rules?

Some Statements:
----------------
The following is an attempt to simplify the thinking by defining what is =

inside of our scope and what is outside. Please discuss furiously:

SHTTP assumes that the security modules that secure elements in the data =

stream either have the key/certificate available at download time, or tha=
t
the downloaded document can be stored locally while the key is acquired. =
In
the latter case the user must have been told how to get the key.

Each security extension, a set of code modules, is responsible for provid=
ing
key storage and access mechanisms.

Each secure server/site, based on the actual security mechanism, is
responsible for providing the mechanisms by which keys are destributed,
certified, etc.

Harald Skardal, <harald@ftp.com>
FTP Software.
N. Andover, MA, USA.

"One who has both feet on the ground is not moving forward."