Enhance tkstool for capabilities and security
This simple ticket is to fix tkstool to allow it
to create the master key with the proper flags to make
the key data private such that it can't be easily viewed when
using tools to print out sym keys on the token.
Fix tested on the "internal" token by trying the various tkstool
cmds to make sure having the key private does not cause issues.
Also tried a simple key changeover operation with tpsclient to make
sure that symkey can still do what it needs to do witht the master key.
Further testing with a full hsm will be required.
The goal was the create the key with the same flags that are used with the
previous "PK11_GenKeyOnToken" (name approx) is used. This version had no
flags and created a default set. This fix uses the version With flags and
does what the old one did, but made sure the key is private and sensitive.
Master key can be tested by using the tool:
/usr/lib64/nss/unsupported-tools/symkeyutil -d ./ -L
The attached patches implement replication support for lightweight
CAs. These patches do not implement key replication via Custodia
(my next task) but they do implement the persistent search thread
and appropriate** API behaviour when the signing keys are not yet
** In most cases, we respond 503 Service Unavailable; this is open
for discussion. ca-authority-find and ca-authority-show include
a boolean field indicating whether the CA is ready to sign.
There might be (probably are) endpoints I've missed.
Currently when installing an additional subsystem to an existing
instance the install tool always generates a new random password in
the pki_pin property which would not work with the existing NSS
database. The code has been modified to load the existing NSS
database password from the instance if the instance already exists.
The PKIInstance class has been modified to allow loading partially
created instance to help the installation.
Endi S. Dewata
Some variables in pkispawn and pkidestroy have been renamed for
The unused PKI_CERT_DB_PASSWORD_SLOT variable has been removed.
The constant pki_self_signed_token property has been moved into
Endi S. Dewata
Lightweight CA key replication is taking shape. I have updated the
design page with juicy details:
Could interested parties and Simo please eyeball it. Simo, I
particularly want your feedback on feasibility / implications of
creating a Kerberos principal for each CA replica which will be
authorised as a Custodia client to retrieve sub-CA signing keys.
Alternatively, instead of adding another principal could we use the
existing HTTP/<hostname>@<realm> principal as the Custodia client?
I entertained implementing TLS certificate authentication for
Custodia so that we could authenticate using e.g. CA subsystem cert
but felt that GSS-API would be a smoother path, becaues we already
have Python client code for IPA.
The implementation is in-progress; most of the core Java bits are
done, but not yet the IPA-specific KeyRetriever implementation nor
the Python helper program.
P.S. I made a number of other updates to the design page - mostly
updates to bring it in line with what's already been implemented.
In the external CA case if the externally-signed CA certificate
is included in the certificate chain the CA certificate may get
imported with an incorrect nickname.
The code has been modified such that the certificate chain is
imported after the CA certificate is imported with the proper
ACKed by mharmsen (thanks!). Pushed to master.
Endi S. Dewata
Attached please find the patch for ticket 1006:
https://fedorahosted.org/pki/ticket/1006 Audit logging for TPS REST
Most of the work is on
1. finding the right places to place the audit calls
2. deciding on what should be audited: since all read operations are
captured by AUTZ, the REST operations audited are only write operations
3. deciding on the audit events that should be provided for the operations
4. making needed information available at the places where auditing is
The TPS subsystem has been modified to generate the token state
transitions from TEMP_LOST to UNINITIALIZED or ACTIVE dynamically
depending on whether the token has certificates.
The TEMP_LOST to ACTIVE transition has been removed from the CS.cfg.
Duplicate code that loads the allowed transitions list has been
merged and moved into TPSSubsystem.
Endi S. Dewata