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@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