> > In order to be trusted, the security provider must be signed with a > > key that was certified by the JCE Code Signing Certification > > Authority (see Step 5 of the document above). > > So why can't we ship trusted root certificates for a Debian Code > Signing Certification Authority, or trust everything which is present > in the file system? Your first proposition sounds reasonable at first glance, though I would like some feedback from others who are more familiar with the free JVMs that ship with Java. > I have the strong suspicion that this certificate just asserts that > you have signed the CSR form and promised to comply with U.S. export > regulations, and nothing else. Maybe this was the result of a deal > between BXA/BIS and Sun which permitted Sun to export their > implementation. We don't need to follow such a procedure because > Debian has different means to comply with the regulations, and we do > not distribute Sun's implementation, AFAIK. Though we don't distribute Sun's implementation, java-package provides a straightforward way to insall Sun's installation on a Debian machine. Further, due to what appears to be a Classpath bug, no free JVM that we do ship is able to pass all of the BouncyCastle regression tests (which is why BouncyCastle is currently in contrib). Does anyone from debian-java know how the free JVMs deal with security providers? Charles -- Always remember On any trip Keep two things Within your grip Your steering wheel and Burma-Shave http://burma-shave.org/jingles/1940/always_remember
Attachment:
signature.asc
Description: Digital signature