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

[Ade Lee]

On Mon, 2012-01-09 at 11:52 -0500, Ade Lee wrote:
> 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
> 
> 
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

actually - just looking at this -- I'm thinking :

Here is what I see so far:
For scenario 6: 
    GET /pki/keyrequests/requestState=pending --> get a list of pending requests
    GET /pki/keyrequests/requestState=pending;requestType=recovery --> get a list of pending recovery requests
For scenario 7:
    GET /pki/keyrequests/requestState=approved;requestType=recovery--> 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)

GET /pki/keyrequests/requestType={type};requestState={state}

ie. using matrix parameters for all searches to be consistent.

Ade