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

[Ian G]

Nicolas Williams wrote:
> On Mon, May 14, 2007 at 11:06:47AM -0600, zooko at zooko.com wrote:
>>  Ian G wrote:
>>> * Being dependent on PKI style certificates for signing, 
>> ...
>>
>> The most important motivation at the time was to avoid the risk of Java being
>> export-controlled as crypto.  The theory within Sun was that "crypto with a
>> hole" would be free from export controls but also be useful for programmers.
> 
> "crypto with a hole" (i.e., a framework where anyone can plug anyone
> else's crypto) is what was seen as bad.


But that's what they've got.  If the theory was that they 
needed to provide crypto without a hole, then they shouldn't 
have provided the crypto.  *The framework is the hole*, and 
pretending to stop other holes from being added is a fool's 
game.

Which isn't to say that this is the end of the story.  The 
story was no doubt very complex.

Some topic drift (as Lynn would say):  I did a fair bit of 
investigation on the SSL v1 -> v2 transition and discovered 
10 different forces working at the time.  As a historical 
comparison, we can suggest that Sun's Java group faced the 
same messy cauldron of forces at the time of the JCA being 
designed.  In that historical investigation I concluded that 
Netscape could not avoid the forces, and quite possibly ("no 
surprise") the Sun group cannot avoid the forces either.


> 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?

The point is that once we agree that this is an "outside" 
requirement, then we can see that as it starts to impact the 
security architecture, it can only worsen the security.


> 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:

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.)

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

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


> 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 
a good case study of how the software engineering department 
put in place a heavyweight structure that drifted away from 
security.  We can learn from that.

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?

iang

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