no surprise - Sun fails to open source the crypto part of Java

[Nicolas Williams]

On Tue, May 15, 2007 at 11:37:56AM +0200, Ian G wrote:
> Nicolas Williams wrote:
> >The requirement for having providers signed by a vendor's key certified
> >by Sun was to make sure that only providers from suppliers not from,
> >say, North Korea etc., can be loaded by the pluggable frameworks.
> 
> OK, but can we agree that this is a motive outside normal 
> engineering practices?  And it is definately nothing to do 
> with security as understood at the language and application 
> levels?

If we ignore politics, and if we ignore TPMs, yes.  Those are big
caveats.

> >As
> >far as I know the process for getting a certificate for this is no more
> >burdensome to any third parties, whether open source communities or
> >otherwise, than is needed to meet the legal requirements then, and
> >since, in force.
> 
> From what the guys in Cryptix have told me, this is true. 
> Getting the certificate is simply a bureaucratic hurdle, at 
> the current time.  This part is good.  But, in the big picture:

Good.

> J1.0:  no crypto
> J1.1:  crypto with no barriers
> J1.2:  JCA with no encryption, but replaceable
> J1.4:  JCA with low encryption, stuck, but providers are easy
> J1.5:  JCA, low encryption, signed providers, easy to get a 
> key for your provider
> J1.6:  ??
> 
> (The java version numbers are descriptive, not accurate.)

I'm not sure I understand the significance of the above.  I'm sure that
there are better lists to ask about the prospects for evolution here.

> The really lucky part here is that (due to circumstances 
> outside control) the entire language or implementation has 
> gone open source.

That's not due to luck.

> No more games are possible ==>  outside requirements are 
> neutered.  This may save crypto security in Java.

Save it from what exactly?

> >Of course, IANAL and I don't represent Sun, and you are free not to
> >believe me and try getting a certificate as described in Chapter 8 of
> >the Solaris Security Developers Guide for Solaris 10, which you can find
> >at:
> 
> 
> Sure.  There are two issues here, one backwards-looking and 
> one forwards-looking.
> 
> 1.  What is the way this should be done?  the Java story is 

By whom?  The code is GPLed -- you're free to hack on it.  OpenSolaris
is CDDLed and you're free to hack on that too.

Sun may or may not be subject to more relaxed export rules as a result
of open sourcing these things.  I don't know, IANAL.  The point is that
Sun may not be able to do in the products it ships what the community
can do with the source code.

> 2.  What is needed now?  Florian says the provider is 
> missing and the "root list" is empty.  What to do?  Is it 
> time to reinvigorate the open source Java crypto scene?

Ah, but you're free to: the code is GPLed and you can figure out what to
do to make the crypto framework not require provider signing.

Also, the provider surely can't be missing due to export rules -- the
C/assemler equivalents in Solaris are open source.

Nico
-- 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com