Re: no surprise - Sun fails to open source the crypto part of Java
On Mon, May 14, 2007 at 11:06:47AM -0600, [EMAIL PROTECTED] 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. 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. 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. 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: http://docs.sun.com Comments should probably be sent to [EMAIL PROTECTED] Cheers, Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: no surprise - Sun fails to open source the crypto part of Java
Nicolas Williams wrote: On Mon, May 14, 2007 at 11:06:47AM -0600, [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: no surprise - Sun fails to open source the crypto part of Java
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 [EMAIL PROTECTED]
Re: no surprise - Sun fails to open source the crypto part of Java
Nicolas Williams wrote: Subject: Re: no surprise - Sun fails to open source the crypto part of Java Were you not surprised because you knew that said source is encumbered, or because you think Sun has some nefarious motive to not open source that code? Third option: the architecture of Sun's Java crypto framework is based on motives that should have been avoided, and have come back to bite (again). The crypto framework in Java as designed by Sun was built on motives (nefarious, warped or just plain stupid, I don't know) such as * the need or desire to separate out encryption from authentication, and deliver two compatible but varying implementations in one variable body of code. With a switch. Somewhere. * some notion that crypto code should be (must be) a competitive market, one that is created by Sun, and is controlled by Sun. * circular dependency where we have to install a signed provider which means we need signing which means we need crypto ... * Being dependent on PKI style certificates for signing, so for example, if your machine doesn't have a properly configured domain name, touching the crypto caused DNS timeouts ... (1.5 from memory, might be fixed). Hence, the framework is clumsy in practice, and trying to change it (in any way) was likely to run into roadblocks at the legal, policy and other areas like rights ... As an aside, security is the baby that got thrown out with the bathwater. If the latter then keep in mind that you can find plenty of crypto code in OpenSolaris, which, unless you think the CDDL does not qualify as open source, is open source. I've no first hand knowledge, but I suspect that the news story you quoted from is correct: the code is encumbered and Sun couldn't get the copyright holders to permit release under the GPL in time for the release of Java source under the GPL. The real interest was whether there was any difficulty in modifying the source code to add in the parts needed. As Florian points out (thanks!), it is Sun's Provider that has not been delivered. This is good, that is the part that is intended to be replaceable, so any of the Cryptix or Bouncy Castle or IAIK providers can be easy alternatives. My worry was that they hadn't open sourced the architecture component, the part that wasn't meant to be replaceable. However even if open sourced, Sun may still wield a stick over the providers by insisting that they manage the signing process for the providers. (This is in effect what open source organisations like Mozilla do with their source. There is a tiny hook in there that stops people from changing the root list.) iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: no surprise - Sun fails to open source the crypto part of Java
Ian G wrote: Third option: the architecture of Sun's Java crypto framework is based on motives that should have been avoided, and have come back to bite (again). The crypto framework in Java as designed by Sun was built on motives (nefarious, warped or just plain stupid, I don't know) such as * the need or desire to separate out encryption from authentication, ... * some notion that crypto code should be (must be) a competitive market, ... * circular dependency ... * 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. Regards, Zooko - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: no surprise - Sun fails to open source the crypto part of Java
* Ian G.: My worry was that they hadn't open sourced the architecture component, the part that wasn't meant to be replaceable. However even if open sourced, Sun may still wield a stick over the providers by insisting that they manage the signing process for the providers. The signing provider PKI is a joke, it's sole purpose is to ensure that Sun has got a fax allegedly from you in which you promise that you will comply with applicable export regulations. The root CA list shipped in OpenJDK should be empty at this stage (at least this is mentioned somewhere on the OpenJDK web page) because it is not clear what the criteria are to populate it. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: no surprise - Sun fails to open source the crypto part of Java
[EMAIL PROTECTED] (Ian G) on Monday, May 14, 2007 wrote: Third option: the architecture of Sun's Java crypto framework is based on motives that should have been avoided, and have come back to bite (again). I think it is likely that Sun architected the Java crypto framework to be able to obey the letter of the export regulations then in effect. They made it so the actual crypto implementations could differ from country to country, and from supplier to supplier, while trying (not very successfully IMHO) to provide a consistent application interface. Cheers - Bill --- Bill Frantz| I like the farmers' market | Periwinkle (408)356-8506 | because I can get fruits and | 16345 Englewood Ave www.pwpconsult.com | vegetables without stickers. | Los Gatos, CA 95032 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: no surprise - Sun fails to open source the crypto part of Java
* Ian G.: Does anyone know what Sun failed to opensource in the crypto part of Java? The Sun JCE provider appears to be missing, which means that few cryptographic algorithms are actually implemented in the source drop. All the symmetric encryption algorithms are missing, for instance. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: no surprise - Sun fails to open source the crypto part of Java
Subject: Re: no surprise - Sun fails to open source the crypto part of Java Were you not surprised because you knew that said source is encumbered, or because you think Sun has some nefarious motive to not open source that code? If the latter then keep in mind that you can find plenty of crypto code in OpenSolaris, which, unless you think the CDDL does not qualify as open source, is open source. I've no first hand knowledge, but I suspect that the news story you quoted from is correct: the code is encumbered and Sun couldn't get the copyright holders to permit release under the GPL in time for the release of Java source under the GPL. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: no surprise - Sun fails to open source the crypto part of Java
On Fri, May 11, 2007 at 04:42:47PM +0200, Ian G wrote: They also involve some elements of sound and cryptography, said Tom Marble, Sun's OpenJDK ambassador. We have already contacted the copyright holders. We were unable to negotiate release under an open-source license, Marble said. I believe at least some versions of Java used RSADSI's JSAFE for the low-level crypto code, which would explain why that portion of it wasn't included. -Jack - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
