From: minow@apple.com (Martin Minow)
Date: Mon, 3 Jun 1996 03:40:56 +0800
To: cypherpunks@toad.com
Subject: Re: Java Crypto API questions
Message-ID: <v02140b01add765d5419c@[17.128.200.24]>
MIME-Version: 1.0
Content-Type: text/plain


>Today, CP's own Marianne Mueller was scheduled to give a talk at JavaOne on
>the eagerly awaited (at least by this user) Java Crypto API.

Here are my notes (and between-the-lines observations) from the Java crypto
sesions (which were very well received). Watch the Java web sites for
transcripts from JavaOne sessions. (but I don't know if the BOF will be
available).

-- Security is *important* -- zero tolerance for security bugs.
   Gosling said in his keynote that it changes things when people
   send their bug reports to USA Today.
-- They're working with standards folk: W3C, IETF.
-- Clean, simple design, paying attention toll aspects of security
   design: language, virtual machine, components (libraries).
-- Adding digital signatures to code enables greater trust -- the
   user can allow an applet to "escape from the sandbox."
-- Policies = Assertions + Capabilities. That's what my notes
   say -- I think it means that the user can use a signature
   to authenticate the applet's author/publisher and allow it
   greater capabilities. For example, a stock trading applet
   might be granted the capability to access a stock price service
   (Dow Jones) *and* a stock trading service. The current applet
   model only allows remote connection to the site that distributed
   the applet.
-- Java will allow signing archives (a set of classes and resources).

-- Network-centered security: digital signatues, encryption, key exchange,
   hash, bignum, random number generators.
-- Packages (third-party applets) communicate with security packages
   through an abstract layer. There may be multiple packages.
-- They will provide a secure key storage (like Apple's PowerTalk
   today, I presume) where "all" of your keys are held under a
   a single password. Rogue applications (applets?) can't leak keys.
-- Feedback to security-api@java.sun.com.
-- There's a white paper on the verifyier on the sun web site.
-- They're writing a security policy for applications (applications
   function like "ordinary" Unix/Mac/whatever applications.
-- User preference to designate capabilities for signed/unsigned
   applets.

---- ---- ----
Notes from the security birds of a feather session
---- ---- ----

-- Need multiple security managers: if any say no, reject the request.
-- Servet, applet need different security managers.
-- Problem with firewalls: client accesses server via firewall via
   proxy servers. May not be able to open a URL directly.
-- Java Commerce API coming for payment functions.
-- Problem with foreign applet vendors: how can a non-US security
   class vendor certify a class to be used (outside the US).
   Currently, it must be imported and signed by Sun. But, then
   it can't be exported without a Commerce Department license.
   No (current) plans to establish a signing authority outside
   of the U.S.

Martin Minow
minow@apple.com