Date: Mon, 28 Jul 1997 10:49:53 -0700
Message-Id: <199707281749.KAA10972@puffin.eng.sun.com>
From: Marianne Mueller <mrm@Eng>
To: Valik@alis.kharkov.ua
Subject: Re: Questions again :)
> Organization: Alis Software
> From: "Valentin Perepelitsa" <Valik@alis.kharkov.ua>
> Date: Mon, 28 Jul 97 19:01:48 +0300
>
> Hello again, Marianne!
>
> I've got a next packet of questions.
>
> Suppose Client is to be the host, where applet executes, and Server is to
> be a host, where applet was loaded from.
This is how we typically use the terms server and client - that's the
right terminology.
>
> 1. What the privilegies can gain applet on the Client part?
What application is running the client? There are several
Java-enabled browsers - Netscape Navigator, Netscape Communicator,
Microsoft Explorer, and JavaSoft's HotJava. Of those browsers, only
HotJava has integrated support for Java digital signatures. So, it's
not possible to assign privileges to signed applets (if they're signed
with the standard Java digital signature format, as in the JDK),
unless you are using HotJava, which I guess few people are.
So, the short term answer is, there's not much practical that you can
do, to assign privileges. The longer term answer is, I hope that we
get to a state of interoperability with digital signatures, with the
vendors who create Java-enabled browsers.
> 2. Where Client can take "public" key to applet authentication
checking?
The Java application itself doesn't do the authentication checking,
but rather, the Java-enabled browser (or base client application) does
this. There are two parts to checking a signature, roughly speaking.
One part is the pure math: just checking that the signature is
mathematically accurate. The other is the policy: checking that the
signed archive has been signed in accordance with some internal
policy, like "the certificate must be no older than 7 days" or "the
certificate must itself be signed by a trusted Certificate Authority."
The policy questions can get quite elaborate and as you see, they are
very different from the "pure math" checks, which simply look to see
if the bits are OK.
> 3. How to place "public key" on the authority servers (if there is existing
> one) so specified server will know that it is a key for it?
The current Certificate Authorities don't support certificates for the
DSA algorithm, which is the algorithm used for Java digital
signatures. We are working on establishing a working relationship
with a CA that will register certificates for Java DSA keys. For
now, each enterprise should experiment with their own internal
certificate store (the support for certificate storage and management
will improve with upcoming JDK releases.)
> 4. Where can I find information about security authority servers?
If you mean Certificate Authority, look at
Verisign
Nortel
Entrust
Netscape and Microsoft both have agreements with CAs (Certificate
Authorities)
> 5. Do the privilegies have the inheritence? I mean, if one signed applet
> invokes another not signed applet (or not signed class), will the derived
> applet (class) has same privilegies?
It depends on the security model of the underlying application.
In JDK 1.2, (the upcoming release of the Java Development Kit),
privileges are not transferred. Rather, the effective privilege is
the intersection of privileges. If applet A has permissions "a,b,c"
and applet B has permissions "b,c,d", then when applet A calls applet B,
the effective permisssion are "b,c".
>
> Thanks a lot for wasting time.
> ---
> Regards,
> Valentin Perepelitsa
>