-
Bug
-
Resolution: Fixed
-
P4
-
5.0
-
b96
-
generic
-
generic
Here is the list of "How to Implement a Provider for JCE" doc changes for JCE tiger-beta2 release:
1. Update the version to be 1.5 wherever appropriate. For example, under section "Introduction", the version number "1.4" in the sentence "The Java 2 SDK, v 1.4 release comes standard with a JCE provider named ..." should be replaced with "1.5". However, for certain sentences, it may be more appropriate to slightly rephrase instead of changing the version number, such as the following:
"JCE has now been integrated into the Java 2 SDK, v 1.4" should be rephrased to "JCE has been integrated into the Java 2 SDK since version 1.4".
2. Under section "Introduction", we should update the list of cryptographic services supported by "SunJCE" provider with the new algorithms added in tiger release. In addition, the existing list is not well-organized and should be
improved so the supported algorithms can be found with a quick glance.
I'll provide info on the currently supported crypto services in the "Comments" section later.
3. In section "A Note on Terminology", the first item has "This framework includes everything in the javax.crypto package." This statement is somewhat incorrect. This framework actually include everything in the three packages, i.e. "javax.crypto", "javax.crypto.spec", "javax.crypto.interfaces".
4. Given that this doc is for 1.5, I am not sure if we should still put the emphasize on the difference between JCE 1.2.1 and the JCE in the Java 2 SDK, v 1.4 as documented under the "What's New in JCE" section. It maybe more appropriate to put the different between JCE 1.2.1 and Java 2 SDK v1.4 into an Appendix, so people can go look if interested.
5. In the section "Step 3: Write your 'Master Class'", we should enhance the example of using one generic DES class that subclasses from CipherSpi. According to current doc, the provider would have the following Cipher properties in its master class:
* "Cipher.DES"
However, we should also add the following to the above list:
* "Cipher.DES SupportedModes" <= one example value is "ECB|CBC|CFB|OFB"
* "Cipher.DES SupportedPaddings" <= one example value is "PKCS5Padding"
6. Close to the end of the same section as of #5, the paragraph which describes how Cipher.getInstance() works need to be re-written as the lookup mechanism has been modified/changed by ###@###.###. The paragraph starts with the sentence "The getInstance factory method of the Cipher engine class follows these rules in order to instantiate a provider's implementation of CipherSpi for a ..." and lasts til the end of the section.
7. Under section "Step 5a: Get a Code-Signing Certificate", the sentence of " 1. Use keytool to generate a DSA keypair" is better phrased as "Use keytool to generate a keypair, using DSA algorithm as an example". In addition, the command line for using keytool to generate a certificate signing request should be modified so that the "-sigalg DSA" is removed since keytool can figure out the
signature algorithm based on the key type.
8. Under section "Configuring the Provider", the paragraph which states the following
====== OLD ======
The Java 2 SDK, v 1.4 comes standard with a provider named "SUN", which is automatically configured as a static provider in the java.security properties file, as follows:
security.provider.1=sun.security.provider.Sun
=================
need to be updated to
====== NEW ======
The Java 2 SDK, v 1.5 comes standard with two providers named "SUN" and "SunRsaSign", which are automatically configured as static providers in the java.security properties file, as follows:
(the first statically registered provider is for PKCS11 providers)
security.provider.2=sun.security.provider.Sun
security.provider.3=sun.security.rsa.SunRsaSign
=================
Please note that the subsequent paragraph for registering the alternate provider has the wording "giving it whatever preference order you prefer". This should also be changed into "giving it a lower preference order than the "SUN" and "SunRsaSign" providers". This would also affect the example which registers the CryptoX provider at preference "2" to "4".
9. The section "Algorithm Parameter Specification Classes" should include class javax.crypto.spec.OAEPParameterSpec which is added in tiger
10. Appendix A and C need to be updated with what's in tiger release.
1. Update the version to be 1.5 wherever appropriate. For example, under section "Introduction", the version number "1.4" in the sentence "The Java 2 SDK, v 1.4 release comes standard with a JCE provider named ..." should be replaced with "1.5". However, for certain sentences, it may be more appropriate to slightly rephrase instead of changing the version number, such as the following:
"JCE has now been integrated into the Java 2 SDK, v 1.4" should be rephrased to "JCE has been integrated into the Java 2 SDK since version 1.4".
2. Under section "Introduction", we should update the list of cryptographic services supported by "SunJCE" provider with the new algorithms added in tiger release. In addition, the existing list is not well-organized and should be
improved so the supported algorithms can be found with a quick glance.
I'll provide info on the currently supported crypto services in the "Comments" section later.
3. In section "A Note on Terminology", the first item has "This framework includes everything in the javax.crypto package." This statement is somewhat incorrect. This framework actually include everything in the three packages, i.e. "javax.crypto", "javax.crypto.spec", "javax.crypto.interfaces".
4. Given that this doc is for 1.5, I am not sure if we should still put the emphasize on the difference between JCE 1.2.1 and the JCE in the Java 2 SDK, v 1.4 as documented under the "What's New in JCE" section. It maybe more appropriate to put the different between JCE 1.2.1 and Java 2 SDK v1.4 into an Appendix, so people can go look if interested.
5. In the section "Step 3: Write your 'Master Class'", we should enhance the example of using one generic DES class that subclasses from CipherSpi. According to current doc, the provider would have the following Cipher properties in its master class:
* "Cipher.DES"
However, we should also add the following to the above list:
* "Cipher.DES SupportedModes" <= one example value is "ECB|CBC|CFB|OFB"
* "Cipher.DES SupportedPaddings" <= one example value is "PKCS5Padding"
6. Close to the end of the same section as of #5, the paragraph which describes how Cipher.getInstance() works need to be re-written as the lookup mechanism has been modified/changed by ###@###.###. The paragraph starts with the sentence "The getInstance factory method of the Cipher engine class follows these rules in order to instantiate a provider's implementation of CipherSpi for a ..." and lasts til the end of the section.
7. Under section "Step 5a: Get a Code-Signing Certificate", the sentence of " 1. Use keytool to generate a DSA keypair" is better phrased as "Use keytool to generate a keypair, using DSA algorithm as an example". In addition, the command line for using keytool to generate a certificate signing request should be modified so that the "-sigalg DSA" is removed since keytool can figure out the
signature algorithm based on the key type.
8. Under section "Configuring the Provider", the paragraph which states the following
====== OLD ======
The Java 2 SDK, v 1.4 comes standard with a provider named "SUN", which is automatically configured as a static provider in the java.security properties file, as follows:
security.provider.1=sun.security.provider.Sun
=================
need to be updated to
====== NEW ======
The Java 2 SDK, v 1.5 comes standard with two providers named "SUN" and "SunRsaSign", which are automatically configured as static providers in the java.security properties file, as follows:
(the first statically registered provider is for PKCS11 providers)
security.provider.2=sun.security.provider.Sun
security.provider.3=sun.security.rsa.SunRsaSign
=================
Please note that the subsequent paragraph for registering the alternate provider has the wording "giving it whatever preference order you prefer". This should also be changed into "giving it a lower preference order than the "SUN" and "SunRsaSign" providers". This would also affect the example which registers the CryptoX provider at preference "2" to "4".
9. The section "Algorithm Parameter Specification Classes" should include class javax.crypto.spec.OAEPParameterSpec which is added in tiger
10. Appendix A and C need to be updated with what's in tiger release.