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/25 > 32 > > 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 _______________________________________________ Pki-devel mailing list Pki-devel(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-devel