[7197] in Kerberos
Re: Kerberos and JAVA
daemon@ATHENA.MIT.EDU (Dennis Glatting)
Thu May 2 12:16:03 1996
From: Dennis Glatting <dennisg@plaintalk.bellevue.wa.us>
Date: Thu, 2 May 96 08:50:02 -0700
To: Sam Hartman <hartmans@MIT.EDU>
Cc: jwk3@acpub.duke.edu (Jay Kamm), kerberos@MIT.EDU
Reply-To: dennis.glatting@plaintalk.bellevue.wa.us
From: Sam Hartman <hartmans@mit.edu>
Date: 02 May 1996 11:32:58 -0400
> >>>>> "Dennis" == Dennis Glatting <dennisg@plaintalk.bellevue.wa.us> writes:
>
> Dennis> With the potential of tens of thousand clients, how would
> Dennis> you handle upgrades or bug fixes to the native code?
>
> The same way you handle upgrades to the native SSL code.
>
What is that?
> Security is something that you don't want to be leaving up
> to content providers, because without native security
> code, you can't verify the authenticity and integrity of
> any additional security code downloaded from a content
> provider.
>
You do not want to leave it up to the client too. Many people
use computers every day who are not knowledgeable of
security matters, much less capable of upgrading their
word processor. Should they be less secure because
computer matters are not their forte?
The authenticity of modules could be verified if the
run-time system has a rudimentary method of doing so. For
example, transfer of a module tagged "security thingy"
would have to be accompanied by a MD5 checksum of the
module signed by the provider, whose signature is signed
by the Java god.
-dpg
