Hi, I am currently implementing two new features and would like to discuss some issues about this:
1. Java keystore download (RFE 1009969) I have implemented a Java tool that allows to create Java keystores on the command line. Required input (currently): - End entity certificate (DER format) - End entity RSA key (PKCS#8, *not* encrypted) - CA certificate (DER format) - optionally certificates of the cert chain up to root (all DER format) - Symbolic label names for each of the above entries (e. g. CERT, KEY, CACERT, ROOTCACERT) - RSA key password (PIN protecting the private key in the key store) - Keystore password (PIN protecting the whole keystore) I'd like to add the Java Keystore download option everywhere where a PKCS#12 download is offered by the GUI. Questions: - thoughts, ideas, objections? - can I just add the new tool to src/ directory? - currently it is only possible to get the own CA certificate from the DB, isn't it? The var/crypto/chain directory may contain the required certificates, but it is not really enforced, right? Do you think it is sensible to construct the keystores based on the CA certs that are available, e. g. if the other CA certs are found in var/crypto/chain then use them, otherwise only include cert and cacert in the keystore. - due to limitations of the &*$ Java JCE stuff it is not possible to handle encrypted PKCS#8 keys, so I have to provide an unencrypted key. I will have to write it to a temp file (mode 400) and delete it immediately after the operation. OK? - somehow I have to provide the Java tool with the passwords for key and keystore. This is currently done on the commandline. Drawback: it briefly shows in the ps command. Another approach would be to pipe the stuff into the Java command via STDIN. Environment is not accessible by Java, AFIK. 2. Random pin generation (RFE 1009984) Already implemented. Now I am thinking of integration into OpenCA. What I have done: New pub.conf configuration entry: ProvideServerGeneratedPin (default: NO) If set to yes, the dialog for user certificate requests (currently only basic_csr) is changed: - the first Pin entry field is changed to a hidden field, the PIN value is precomputed using OpenCA::OpenSSL::getPIN. Length is MinPinLength from configuration. Pin is printed out on the HTML form. - second Pin entry form is unchanged The user must still enter the displayed PIN in the second form to acknowledge that a) he noticed there IS a pin b) he could read the characters displayed properly. (Nobody keeps him from cut-and-pasting the Pin, but that's the user's problem.) The displayed texts can be kept the same and the behaviour of the user interface does not change at all, so I think this is not a very obtrusive change. Questions: - any objections against this approach? - should I only apply the change to basic_csr and ldapCreateCSR (the only places where private keys are generated) or should it also apply to other requests (pkcs10...)? Martin ------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ OpenCA-Devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/openca-devel
