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