Here is the first (rough) cut of IEC 62351-8 (IECUserRoles)
extension support and a DNP3 profile that makes use of it. This is
to meet (some of) the PKI needs for the "Smart Grid" DNP3 Secure
Authentication v5 (SAv5) standard.
In brief, the SN and all the IECUserRoles params will be given in
profile inputs, and the key is taken from a CertReqInput.
There's still a bit of work to go - notably, some of the
IECUserRoles fields are unimplemented, and some of those that *are*
implemented are not yet read out of the profile input but rather are
hardcoded. The extension *does* appear on the certificate, so I
should get that all completed tomorrow.
The RAEnrollProfile class is not used or referenced anywhere in the
codebase. I presume it was related to the RA, but even immediately
before removal of the RA it did not seem to be used, so it seems
safe to remove it.
Along with LDAP profiles, we will be adding modules to the CLI for
adding and editing profiles in the ConfigStore format that was used
for file-based profiles. For more info, see:
There is an existing CLI for adding and modifying profiles, in the
XML format, e.g. ``pki ca profile add caCustomProfile.xml``. The
XML format carries information including the profile ID and
class_id, but these data must be supplied out-of-band when dealing
with the ConfigStore format.
Because of this, I intend to:
- add new commands to the existing profile CLI for working with the
"raw" (i.e., ConfigStore) format, e.g. "edit-raw", "add-raw".
Where necessary, these commands will take compulsory
``--profile-id`` and/or ``--class-id`` arguments, to account for
the absense of such information in the profile ConfigStore format;
- transport this information in the XML format - not in the "raw"
format - so that it will be unnecessary to make changes to
ProfileClient or the ProfileService API.
As usual, I welcome feedback - especially if you feel I am going the
wrong way ^_^
This is the first cut of the LDAP profile change monitoring. It
depends on patches 0004..0009 and 0014
To summarise the implementation: a separate thread carries out a
persistent LDAP search and calls back into the ProfileSubsystem when
changes occur. I haven't had much experience with persistent
searches or multithreaded programming in Java, so eyeballs familiar
with those areas are needed.
I haven't yet tested with changes replicating between clones (a task
for tomorrow) but I wanted to get the patch on list for feedback as
early as possible.
Currently web applications are deployed into Host's appBase (i.e.
<instance>/webapps). To allow better control of individual
subsystem deployments, the web applications have to be moved out
of the appBase so that the autoDeploy can work properly later.
This patch moves the common web applications to <instance>/
common/webapps and subsystem web applications to <instance>/
<subsystem>/webapps. An upgrade script has been added to update
Endi S. Dewata
This patch enables the Authority Key Identifier CRL Extension, which
is REQUIRED by RFC 5280, by default.
Should existing instances be left alone or should I also look at an
upgrade script that offers to upgrade CS.cfg to be conformant?
This patch is Part one for tickets:
https://fedorahosted.org/pki/ticket/864 NIST SP800-108 KDF
https://fedorahosted.org/pki/ticket/865 GP Key sanity check
https://fedorahosted.org/pki/ticket/866 pki-common key fixes
The original patches were generated from rhcs8.1, and were submitted by
a community member party that works closely with us. The original
patches have been test-run successfully in a real deployment over a good
period of time.
They apply only to the TMS (token Management System) environment.
Attached please find the patch that I have integrated from the original
patches (see above tickets) into the Dogtag master tree. This is only
the first part, which mainly includes:
1. new code for the symkey JNI changes to support the NIST recommended
Key Derivation functions
2. code changes to pki-core to support the new symkey calls
3. TKS changes to support needed new parameters from TPS
Please note that the needed changes for TPS will come later in a
different patch. This is because the TPS is being rewritten now with
JAVA, so the original c++ patch need more time to be converted.
Because of this, I had to add
4. code changes to TKS to temporarily support the java-based TPS that
has not yet been converted to support NIST SP800-108 KDF
Also, the changes in the original patch for TKSKnownSessionKey selftest
doesn't seem to work. I will need more time to investigate. In order
to get more mileage out of the changed code, I am moving this to the
next part, and temporarily turn off this particular selftest in this
patch, and will be turned back on when it is ready.
Because of the interface changes in symkey, the symkey and pki-core
packages must be updated together.
Because of the complexity and the sheer amount of code involved, Jack, I
will work with you face-to-face on the review of this code.
Finally, no matter how tempted it is to me, I steer away for
reformatting the code, just so that in case we find issues down the
road, we can easily find the right place(s) to discuss with the original
authors. Some time later, once enough mileage is gained, we can
schedule a separate time to reformat it.
It has been tested with simple formats and enrollments with key
archivals. I can continue to perform some more tests while the patch is
Please review the attached patch which address the following tickets:
* PKI TRAC Ticket #1187 - mod_perl should be removed from requirements
* PKI TRAC Ticket #1205 - Outdated selinux-policy dependency.
Additionally, I was able to remove the following Perl runtime
dependencies in this patch:
* perl-Crypt-SSLeay, and
Unfortunately, I was unable to remove the 'perl(File::Slurp)' runtime
dependency since the 'pki-setup-proxy' program and its accompanying
'pkicommon.pm' module both require this runtime dependency. I have
filed PKI TRAC Ticket #1234 - Rewrite 'pki-setup-proxy' in Python
<https://fedorahosted.org/pki/ticket/1234> to rewrite these final Perl
programs as Python thus making Dogtag completely independent of Perl.
The patch was tested by building, installing, and testing all five
subsystems including the tpsclient tool on a 64-bit Fedora 20 machine
which utilized its Directory Server from a remote machine (this was
necessary to be certain that the perl-Mozilla-LDAP package was not
required on the Dogtag machine since it is required by the 389 server).