summaryrefslogtreecommitdiffstats
path: root/base
Commit message (Collapse)AuthorAgeFilesLines
* Fix for Bug 745278 - [RFE] ECC encryption keys cannot be archived.Christina Fu2012-04-058-40/+254
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For the ECC plan and the different phases, please refer to http://pki.fedoraproject.org/wiki/ECC_in_Dogtag Design for each phase is on the same wiki page. Note: the designs beyond phase 2 were more like a brain dump. Although I said "Do Not Review," you are free to take a peak at what's intended down the road. I will go back and take a closer look and refine/adjust the designs when I begin implementation for each new phase. What you need to know: * Problem 1 - nethsm issue: On the server side, if you turn on FIPS mode, in addition to nethsm, you need to attach certicom as well to have ECC SSL working on the server side. This problem has already been reported to Thales last year and they said they'd look into putting the item on their next release. Recently through a different contact, we learned there might be a way to "turn it on" (still waiting for their further instruction) * Problem 2- Certicom issue: This is a show-stopper for deployment. Initially, on the client side, I used Kai's special version of Xulrunner/Firefox, attached to Certicom token, so that the CRMF requests can be generated with key archival option. However, I encountered (or, re-encountered) an issue with certicom token. Certicom generates ECC keys with the wrong format (not PKCS7 conforming), which makes ECC key archival impossible on the server side if you use non-certicom token with DRM (but we expect an HSM in most product deployment). I have contacted Certicom for this issue, and they confirmed that they indeed have such issue. We are hoping they will fix it. But then you might ask, "I thought I saw some ECC enrollment profiles/javascripts being checked in? How were the tests done?" The tests for those profiles were done against this ECC key archival/recovery DRM prototype I implemented last year (needs to be turned on manually in 8.1), where I "cheated" (yeah, that's why it's called a prototype) by decrypting the private key in the CRMF on DRM, and then manipulating the byte array to strip off the offending bytes before archival. In the real, non-prototype implementation, which is what's in this patch, for security reasons, private keys are unwrapped directly onto the token during key archival, so there is no way to manipulate the keys in memory and bypass the Certicom issue. A word about Kai's special version of Xulrunner/Firefox. It is not yet publicly available (due out in Firefox 10.0.4 on RHEL 5.8). * Problem 3- Firefox with nethsm issue: Another option was to connect Kai's special version firefox with an HSM to test my DRM/JSS code. However, for whatever reason, I could not get SSL going between such Firefox and ECC CA ( I did not try very hard though, as I have one other option -- writing my own ECC CRMF generation tool. I might come back to try the nethsm Firefox idea later) My solution (how I work on this official implementation): * I hacked up a ECC CRMF tool by taking the CRMFPopClient (existing in current releases), gutting out the RSA part of the code, and replacing it with ECC code. I call it CRMFPopClientEC. Two types of ECC key pairs could be generated: ECDSA or ECDH (That's another benefit of writing my own tool -- I don't know if you can select which type to generate in the Javascript... maybe you can, I just don't know). I'm in no way condoning archival of signing keys!! This is just a test tool. This tool takes a curve name as option (along with others), generates an ECC key pair, crafts up an CRMF request with key archival option, and sends request directly to the specified CA. You will see a "Deferred" message in the HTML response (see attachment for example) Once CA agent approves the request, the archival request goes to DRM and the user private key is archived. For recovery, DRM agent selects key recovery, etc, and you get your pkcs12. I did some sanity test with the pkcs12 recovered: * Import the recovered pkcs12 into a certicom library: pk12util -d . -h "Certicom FIPS Cert/Key Services" -i userEC.p12 I also tested by retrieving a p12, importing it into a browser, and adding the user as an agent and the user could act as agent via ssl client auth to the CA. Finally, much of the RSA-centric code had been cleared out of the way at the time when I worked on the DRM ECC prototype, so you don't see much of that in this round. How do you test? Well, unless you want to use my CRMFPopClientEC tool hooked up with a nethsm (like I did), or write your own tool, you can't really test it until Certicom fixes their issue. (BTW CRMFPopClientEC can also be changed to work with ceriticom, although you would run into the same issue I mentioned above)
* Replaced deprecated ApacheHttpClientExecutor.Endi Sukma Dewata2012-03-302-16/+6
| | | | | | | The deprecated ApacheHttpClientExecutor class has been replaced with ApacheHttpClient4Executor. Ticket #3
* Added CMSException.Endi Sukma Dewata2012-03-3014-106/+391
| | | | | | | | | | The CMSException was added to simplify error handling in REST services. The exception may include an error message and some other attributes. When the server throws a CMSException (or its subclass), the exception will be marshalled into XML and unmarshalled by the client, then thrown again as a new exception which can be caught by the application. Ticket #100
* Replaced deprecated PK11PubKey.fromRaw().Endi Sukma Dewata2012-03-303-80/+38
| | | | | | | The deprecated fromRaw() method in PK11PubKey has been replaced with fromSPKI(). Ticket #3
* Replaced deprecated RevRequest constructor.Endi Sukma Dewata2012-03-301-9/+8
| | | | | | | The deprecated RevRequest constructor has been replaced with another constructor with null invalidity date. Ticket #3
* Replaced deprecated LDAPConnection.authenticate().Endi Sukma Dewata2012-03-301-23/+6
| | | | | | | The deprecated authenticate() method in LDAPConnection has been replaced with another authenticate() method with different signature. Ticket #3
* Replaced Candlepin with RESTEasy.Endi Sukma Dewata2012-03-296-35/+13
| | | | | | | | | Previously the code depends on the old RESTEasy libraries provided by Candlepin package. Now the Eclipse classpath, build/setup scripts, and the spec file have been updated to use the libraries provided by the new RESTEasy package. Ticket #29
* Replaced deprecated AlgorithmId.getAlgorithmId().Endi Sukma Dewata2012-03-289-143/+122
| | | | | | | The deprecated getAlgorithmId() method in AlgorithmId has been replaced with get(). Ticket #3
* Replaced deprecated JTable.createScrollPaneForTable().Endi Sukma Dewata2012-03-281-1/+1
| | | | | | | The deprecated createScrollPaneForTable() method in JTable() has been replaced with JScrollPane() constructor. Ticket #3
* Replaced deprecated Dialog.show().Endi Sukma Dewata2012-03-282-6/+6
| | | | | | The deprecated show() method in Dialog has been replaced with setVisible(). Ticket #3
* Replaced deprecated JPasswordField.getText().Endi Sukma Dewata2012-03-281-4/+1
| | | | | | | The deprecated getText() method in JPasswordField has been replaced with getPassword(). Ticket #3
* Replaced deprecated DataInputStream.readLine().Endi Sukma Dewata2012-03-283-35/+34
| | | | | | | The deprecated readLine() method in DataInputStream has been replaced by the same method in BufferedReader. Ticket #3
* Replaced deprecated XMLSerializer.Endi Sukma Dewata2012-03-272-16/+19
| | | | | | | | The deprecated XMLSerializer has been replaced with LSSerializer. The new API does not provide a way to control the indentation or line width. Ticket #3
* Added option to build without Javadoc.Endi Sukma Dewata2012-03-263-41/+46
| | | | | | | | | | The build scripts have been modified to provide an option to build without Javadoc to speed up development builds. The option can be used as follows: compose_pki_core_packages --without-javadoc hybrid_rpms Ticket #111
* Removed unnecessary pki folder.Endi Sukma Dewata2012-03-262987-0/+688935
Previously the source code was located inside a pki folder. This folder was created during svn migration and is no longer needed. This folder has now been removed and the contents have been moved up one level. Ticket #131