| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
TMS ECC infrastructure (enrollment with client-side and server-side key generation, and key archival)
|
| |
|
|
| |
internal db in cert status thread.
|
| |
|
|
|
| |
* TRAC Ticket #301 - Need to modify init scripts to verify needed
symlinks in an instance (support non-default instance names)
|
| |
|
|
| |
This allow server to come up with DS where anon binds are turned off.
|
| |
|
|
| |
'Terminated' to be formatted and reused.
|
| |
|
|
| |
- symkey PK11_Derive.
|
| |
|
|
|
| |
* TRAC Ticket #301 - Need to modify init scripts to verify needed
symlinks in an instance
|
| | |
|
| |
|
|
|
|
|
| |
This change needs to be checked in as a patch to f17, rather than
in upstream code. Otherwise it breaks f16.
This reverts commit 868e724716512762ad780f15a10a7a4b88fb1487.
|
| |
|
|
| |
TPS ECC: when TPS server acts as an ECC SSL client to CA, TKS, or DRM, it needs to support ECC ciphers
|
| |
|
|
|
|
|
|
| |
generation
This patch calls with the right flags for each supported HSM to the new
certutil that addressed the following bug:
Bug 820684 - certutil support for EC on HSMs - need to call PK11_GenerateKeyPairWithOpFlags()
|
| | |
|
| |
|
|
|
|
| |
This patch prevents DRM connector to be overwritten by subsequent DRM installations.
Bug 804179.
|
| | |
|
| |
|
|
| |
TPS installation wizard: SizePanel needs to support ECC curve selection
|
| |
|
|
|
|
|
|
| |
ECC support for tpsclient
two parameters are added in the config file (see enroll.tps.ec for example): slotnamefile - this points to a file that contains the slot name. The reason why the slot name goes into another file instead of the conf file is because the existing conf file uses spaces for deliminator and I don't want to change the usage (and QE's tests) by changing it to something else. tokpasswod is the tokebn password
This ECC feature requires the up-coming ECC supporting TPS to trigger. Testing of the ECC specific areas requires the availability of such ECC TPS. Without it, one can test with the old RSA method to see if it's broken.
|
| |
|
|
|
|
|
| |
This patch corrects process of attaching OCSP subsystem to CA.
It improves handling of adding subsequent OCSP subsystems to CA.
Bugs: 804179 and 804176.
|
| |
|
|
|
|
| |
This patch adds ECC directory enrollment profile.
Bug: 748514.
|
| |
|
|
|
|
| |
This patch eliminates CA crash caused by default Android browser.
Bug: 819123.
|
| | |
|
| |
|
|
|
|
| |
This patch provides fix to OCSP agent inability of removing a CA from the List of Certificate Authorities in some circumstances.
Bug: 837124.
|
| |
|
|
|
|
| |
This patch provides verification of revocation reasons and proper handling for removeFromCRLrevocation reason.
Bug: 441354.
|
| |
|
|
|
|
|
| |
Ticket #373
This fix just appends a dummy value to the array, which consumes the error 53.
Patch provided by mreynolds.
|
| |
|
|
|
| |
Added code to add the required ou=cmsusers container to cn=config
on the master if it does not exist, when replication users are set up.
|
| |
|
|
| |
- The real fix is in JSS alone; This patch only adds better error handling and non-static salt.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
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
|
