<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
This is the ECC phase 2 implementation (ECC key archival / recovery
feature) in the JSS and DRM (KRA)<br>
<br>
Bug: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=745278"><b>Bug 745278</b></a>
-<span id="summary_alias_container"> <span
id="short_desc_nonedit_display">[RFE] ECC encryption keys cannot
be archived</span></span><br>
<br>
Please review the following patches (see "BEFORE you review" at
later part of this email):<br>
<br>
*
<a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/attachment.cgi?id=570109&action=diff&context=patch&collapsed=&headers=1&format=raw">https://bugzilla.redhat.com/attachment.cgi?id=570109&action=diff&context=patch&collapsed=&headers=1&format=raw</a><br>
*
<a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/attachment.cgi?id=570110&action=diff&context=patch&collapsed=&headers=1&format=raw">https://bugzilla.redhat.com/attachment.cgi?id=570110&action=diff&context=patch&collapsed=&headers=1&format=raw</a><br>
*
<a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/attachment.cgi?id=570112&action=diff&context=patch&collapsed=&headers=1&format=raw">https://bugzilla.redhat.com/attachment.cgi?id=570112&action=diff&context=patch&collapsed=&headers=1&format=raw</a><br>
<br>
thanks,<br>
Christina<br>
==============<br>
BEFORE you review:<br>
<br>
For the ECC plan and design for the different phases, please refer
to <a class="moz-txt-link-freetext"
href="http://pki.fedoraproject.org/wiki/ECC_in_Dogtag">http://pki.fedoraproject.org/wiki/ECC_in_Dogtag</a><br>
<br>
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.<br>
<br>
This patch contains code for the following packages:<br>
JSS, pki-kra, pki-common, pki-util, and pki-kra-ui<br>
<br>
What you need to know:<br>
<br>
* Problem 1 - nethsm issue:<br>
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)<br>
<br>
* Problem 2- Certicom issue:<br>
This is a show-stopper. 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 waiting for their fix.<br>
<br>
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.<br>
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.<br>
<br>
A word about Kai's special version of Xulrunner/Firefox. It is not
yet publicly available.<br>
<br>
* Problem 3- Firefox with nethsm issue:<br>
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)<br>
<br>
My solution (how I work on this official implementation):<br>
* 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.<br>
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)<br>
Once CA agent approves the request, the archival request goes to DRM
and the user private key is archived.<br>
For recovery, DRM agent selects key recovery, etc, and you get your
pkcs12.<br>
<br>
I did some sanity test with the pkcs12 recovered:<br>
* Import the recovered pkcs12 into a certicom library:<br>
pk12util -d . -h "Certicom FIPS Cert/Key Services" -i userEC.p12<br>
<br>
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.<br>
<br>
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.<br>
<br>
About SELinux:<br>
I have a set of rules generated on my system to run in enforcing
mode. I do a writeup.<br>
<br>
For QE:<br>
How to set up the servers? The internal wiki is at <a
class="moz-txt-link-freetext"
href="https://wiki.idm.lab.bos.redhat.com/export/idmwiki/Working_with_ECC">https://wiki.idm.lab.bos.redhat.com/export/idmwiki/Working_with_ECC</a>.
I might have given someone a copy of how to set up ECC CA to publish
on fedora.org when I worked on phase1 back a couple years ago. I
will put an updated copy to cover both CA and DRM when I am checking
in to dogtag.<br>
<br>
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)<br>
It is not on my schedule to work on this tool; It is certainly not
in production quality to be released as a regular tool. However, if
you are interested in it, if we get enough request maybe we can
think about doing something with it.<br>
Other test suggestion: I did not try to clone the ECC DRM. It's a
good idea to test it out.<br>
<br>
For techpub:<br>
TBD<br>
</body>
</html>