[Pki-devel] [PATCH] 331-333 add support for synchronous key archival and recovery requests.

[Ade Lee]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0338-Fix-approvals-for-asynchronous-requests.patch
Type: text/x-patch
Size: 1412 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20161109/9ea3ea30/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0337-Add-field-to-KeyData-to-allow-request-to-be-returned.patch
Type: text/x-patch
Size: 8866 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20161109/9ea3ea30/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0336-Add-option-to-pass-existing-request-to-retrieveKeyCL.patch
Type: text/x-patch
Size: 6124 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20161109/9ea3ea30/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0335-Modify-retrieval-and-archival-mechanisms-in-KRA-REST.patch
Type: text/x-patch
Size: 49956 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20161109/9ea3ea30/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0334-Refactor-SecurityData-archival-and-recovery-code.patch
Type: text/x-patch
Size: 64521 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20161109/9ea3ea30/attachment-0004.bin>