Thanks for reviews (Endi and Jack). Pushed to master with a few minor
changes to auditing.
Ade
On Wed, 2016-11-09 at 10:59 -0500, Ade Lee wrote:
> 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@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
