[Pki-devel] thinking about searches in the new restful interface

[Ade Lee]

Hi all, 

I have been thinking about what kinds of searches to (initially) expose
in the new restful interface for keys and keyrequests.

Here is the basic idea:
1. A client (ipa) will store a symmetric key or passphrase with a
specified client ID.  For a volume encryption key, this might look
something like "volume-uuid encryption key #1" or "volume-uuid
passphrase #1" for example.   Whatever it is, it needs to be something
that the client (IPA) can later use to retrieve the key if necessary.

2. When the key is archived, the drm will return a reference to the key
stored -- > something like https://foo.com/key/0xdeadbeef.  IPA can
store this value in its database if it wants to - and use it to later
access the key/passphrase.

3. At some point, someone contacts the IPA admin and requests either a
passphrase or a symmetric key.  The admin looks up the volume entry in
the IPA database and sees there is one (or more) passphrases and one (or
more) encryption keys stored for this volume.  

4. The admin then requests the recovery of this volume key.  If the
number of agents required to approve this transaction = 1, then the
admin receives the relevant key.  (I'm ignoring wrapping etc. in this
description).

5. If the number of agents required to approve > 1, then the request is
in pending state.

6. If the request is pending - then other admin(s) can view the request
- and approve it. This approval is sent back to the DRM and the request
state changes accordingly.  Once the correct number of approvals is
obtained, the request is moved to approved state.

7. The admin can then recover key/passphrase.

8.  If a volume is set out of service/ wiped etc. then the admin
notifies the DRM and deletes the entry from the IPA database.  On the
DRM side, the key will either be removed or more likely be marked in the
inactive state.

Based on the scenarios above, I have been trying to determine which
searches the IPA admin might want to be able to do.

Here is what I see so far:
For scenario 6: 
   GET /pki/keyrequests/pending --> get a list of pending requests.
   GET /pki/keyrequests/recovery/pending --> get a list of pending recovery requests
For scenario 7:
   GET /pki/keyrequests/recovery/approved --> get approved (but not yet completed) recovery requests
For scenario 3:
   GET /pki/keys/clientID=foo;status=active
   GET /pki/keys/clientID=foo;status=all
   GET /pki/keys/clientID=foo;status=active;match=approx (return keys with approximate match for client ID)

There are also the standard ones already in the kra web pages (which we can easily expose too) - of which we mention
a couple above:

GET /pki/keyrequests/{type}/{state}


Anything I have missed?
Ade