9:59 a.m.
Based on feedback by Endi, I have reworked the patches.
As Endi pointed out, it makes little sense for the client to determine
whether or not a request is stored to ldap or not. This should be a
server side decision.
Accordingly, I have modified retrieveKey() as follows:
When clients call retrieveKey(), three possible alternatives now
obtain:
1. client passes in an approved request. Request is processed
and the secret is retrieved.
2. client passes in key_id and wrapping parameters and either:
a) request can be processed immediately and synchronously
and request is created, and secret is returned.
b) request cannot be processed immediately. Recovery request
is created and request_id returned to the client
Depending on server configuration, the requests in case (2a) will be
stored in ldap or will be ephemeral (in memory only).
More complicated realm based logic to determine if requests
can be processed synchronously (and possibly ephemerally) will be added
in a later patch.
Python client patches coming soon as well.
***********************************************************************
You can test the patches as follows:
(archive and retrieve a passphrase)
pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname`
-p 8443 key-archive --passphrase "foobar" --clientKeyID "test_1"
pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname`
-p 8443 key-retrieve --keyID 0xc
(retrieve the passphrase using an approved recovery request)
pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname`
-p 8443 key-retrieve --keyID 0xc
pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname`
-p 8443 key-request-review --action approve 0x36
pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname`
-p 8443 key-retrieve --requestID 0x36
The above should create requests (archival and recovery) in LDAP.
Add the following to CS.cfg (and restart the KRA):
kra.ephemeral=true
Redo the above tests, and no requests should be written to LDAP.
Finally, test a case where more than one approval is needed.
Add the following to CS.cfg and restart the KRA.
kra.noOfRequiredSecurityDataRecoveryAgents=2
pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname`
-p 8443 key-retrieve --keyID 0xc
This should return a recovery request ID (which will be written to LDAP).
You will need another agent to approve this request before it can be used to retrieve the
key.
Ade
On Fri, 2016-11-04 at 16:11 -0400, Ade Lee wrote:
Hi all,
This is in support of Ticket https://fedorahosted.org/pki/ticket/2532
This is preliminary set of patches - just so you can see what I'm
doing
in case I need to change anything.
Note: With the changes, you can archive a secret like this:
pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h
`hostname` -p 8443 key-archive --passphrase "ooga booga" --
clientKeyID
"test_1"
pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h
`hostname` -p 8443 key-archive --passphrase "ooga booga" --
clientKeyID
"test_2" --express
The first invocation will archive a secret and create an archival
request in LDAP. The second will create one only in memory - and
will
not store it in LDAP.
You can of course, see the requests created using -
pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h
`hostname` -p 8443 key-request-find
For retrieving the secret, you can do either:
pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h
aleeredhat.laptop -p 8443 key-retrieve --keyID 0x5
pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h
aleeredhat.laptop -p 8443 key-retrieve --keyID 0x5 --express
The first will retrieve the secret while creating a retrieval
request.
The second will create a retrieval request only in memory, and will
not
write it to LDAP.
In both cases, there should be audit logs both for retrieval and
archival.
Thanks,
Ade