[PATCH] 36 Replaced deprecated XMLSerializer.
by Endi Sukma Dewata
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
--
Endi S. Dewata
12 years, 1 month
[PATCH] 35 Added option to build without Javadoc.
by Endi Sukma Dewata
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
--
Endi S. Dewata
12 years, 1 month
[PATCH] 34 Removed unnecessary pki folder.
by Endi Sukma Dewata
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
The patch contains only renames (and minor changes to .gitignore) so it
can be applied in any order unless there's a new/deleted file. If
necessary, outstanding patches can be cherry-picked on top of this patch
without any problem.
Eclipse project will need to be recreated in the top repo folder. The
Eclipse build path might need to be updated too. Anything that calls the
compose scripts will need to use the new path.
--
Endi S. Dewata
12 years, 1 month
[PATCH] pki-vakwetu-0028-Added-policy-deprecations.patch
by Ade Lee
Added policy deprecations
Many of the policy deprecation warnings come from classes that probably ought to
be deprecated as part of the deprecated policy framework as well. Making these
as deprecated removes the deprecation warnings - and we can really see where
we make sure of deprecated policy code elsewhere.
Also removed some URLEncoder, Decoder deprecations
Please review.
Ade
12 years, 1 month
patches for review - ECC key archival / recovery feature implementation - Bug 745278 - [RFE] ECC encryption keys cannot be archived
by Christina
This is the ECC phase 2 implementation (ECC key archival / recovery
feature) in the JSS and DRM (KRA)
Bug: *Bug 745278* <https://bugzilla.redhat.com/show_bug.cgi?id=745278>
-[RFE] ECC encryption keys cannot be archived
Please review the following patches (see "BEFORE you review" at later
part of this email):
*
https://bugzilla.redhat.com/attachment.cgi?id=570109&action=diff&context=...
*
https://bugzilla.redhat.com/attachment.cgi?id=570110&action=diff&context=...
*
https://bugzilla.redhat.com/attachment.cgi?id=570112&action=diff&context=...
thanks,
Christina
==============
BEFORE you review:
For the ECC plan and design for the different phases, please refer to
http://pki.fedoraproject.org/wiki/ECC_in_Dogtag
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.
This patch contains code for the following packages:
JSS, pki-kra, pki-common, pki-util, and pki-kra-ui
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. 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.
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.
* 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.
About SELinux:
I have a set of rules generated on my system to run in enforcing mode.
I do a writeup.
For QE:
How to set up the servers? The internal wiki is at
https://wiki.idm.lab.bos.redhat.com/export/idmwiki/Working_with_ECC. 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.
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)
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.
Other test suggestion: I did not try to clone the ECC DRM. It's a good
idea to test it out.
For techpub:
TBD
12 years, 1 month
[PATCH] 0027-Allow-clones-to-specify-master-and-replica-ports-and.patch
by Ade Lee
Allow clones to specify master and replica ports and security options
Removed -clone_start_tls option and subsumed it into -replicationSecurity.
Refactored DatabasePanel parameter verification code to allow it to be
used in both update() and validate(). Added new parameters to pkisilent
and databasepanel.vm.
Also fixed cloning error when master uses localhost.
This is the second of the split patches. It also addresses issues found
by Endi in review.
Please review.
Ade
12 years, 1 month
[Patch] 0026-Replace-URLEncoder.encode-with-non-deprecated-form-i.patch
by Ade Lee
As requested, I split the previous patch into two patches. One that
deals with deprecations, and one with the replication issues.
This is the one that deals with replications. It still includes the
code to remove the clone_start_TLS code from the pkisilent components
that don't really use it in any case.
I also removed a few obsolete files.
Please review.
Thanks,
Ade
12 years, 1 month
Re: [Pki-devel] Public access and archiving of Red Hat mailing lists [redhat.com #9145767]
by Christina Fu
Hi Rob,
Both pki-user and pki-devel are active mailing lists for subscribers. I
do not see issues with people reading and archiving them. However, in
the past, we have had accounts signed up and spam the aliases, for those
we discovered that they don't go away just by removing them from the
list, we had to ban them.
If there is a better way to handle these, please advise.
thanks,
Christina
On 03/21/2012 11:17 PM, Rob Lowe wrote:
> Hi,
>
> My name is Rob Lowe. I work for Jay Madison in the Red Hat Information
> Security team. I am contacting you in relation to a mailing list which
> you own:
>
> pki-users
>
> It has been brought to our attention that an automated crawler has
> subscribed the address 'archive(a)all-mail-archive.com' to your mailing list
> for the purpose of creating a public archive at:
> http://www.all-mail-archive.com/.
>
> Can you please review pki-users and take appropriate action, such as:
>
> * If the list is no longer used, please consider removing it completely
> or preventing further subscriptions and posts.
>
> * If the list is not intended to be public, please contact
> servicedesk(a)redhat.com and request to have it moved to an internal-only
> list. List content may have already been indexed by crawlers such as
> Google and may appear in search engine caches.
>
> Please note that removing the address 'archive(a)all-mail-archive.com' from
> the mail list will not prevent this issue from re-occuring in the future.
>
> Thank you for your consideration of this request.
>
> Regards,
> Rob
12 years, 1 month
