#2298 [non-TMS] for key archival/recovery, not to record certain data in ldap and logs
Closed: Fixed None Opened 7 years ago by cfu.

There may be desire to not record complete key archival request records in ldap as well as debug log.
This ticket deals with non-TMS only.


After conversations with cfu: 10.3.0

This completes the KRA side of ldap records.

commit 4d41872b88816009ee33963ed61dc32eb6355abe
Author: Christina Fu cfu@redhat.com
Date: Fri May 27 10:43:17 2016 -0700

Ticket 2271 2298 key archival/recovery, not to record certain data in ldap
This patch handles Ticket 2298 non-TMS key archival/recovery, as well as
Ticket 2271 TMS recovery request ldap entries
Fields are zeroed out before being deleted in KRA request records

part 2 deals mostly with CA side of ldap records.

commit 51f34c3edb73a78b42468b756b89d07fc9ec7839
Author: Christina Fu cfu@redhat.com
Date: Thu Jun 16 15:44:58 2016 -0700

Ticket #2298 exclude some ldap record attributes with key archival ^?This is part 2 of: https://fedorahosted.org/pki/ticket/2298 [non-TMS] for key archival/recovery, not to record certain data in ldap and logs

This patch allows one to exclude certain ldap attributes from the enrollment records for crmf requests
(both CRMF, and CMC CRMF).  The following are the highlights:
- CRMF Manual approval profile is disabled: caDualCert.cfg
    - If excludedLdapAttrs.enabled is true, then this profile will not work, as the crmf requests (by default it is false)
    are not written to ldap record for agents to act on
- excludedLdapAttrs.attrs can be used to configure the attribute list to be excluded
- a new CRMF "auto approval" (directory based, needs to be setup) is provided
- if excludedLdapAttrs.enabled is true (in both ca and kra), the following fields are not written to the ldap record in case of CRMF:
(note: the code deliberately use literal strings on purpose for the reason that the exact literal strings need to be spelled out
in excludedLdapAttrs.attrs if the admin chooses to override the default)
           "req_x509info",
           "publickey",
            "req_extensions",
            "cert_request",
            "req_archive_options",
            "req_key"
- Because of the above (possible exclusion of cert requests in record, profiles
  that require agent manual approval will no longer function in the case that
  excludedLdapAttrs.enabled is true
- a sleepOneMinute() method is added for debugging purpose.  It is not called in the final code, but is left there for future debugging purpose
- code was fixed so that in KRA request will display subject name even though the x509info is missing from request
- cmc requests did not have request type in records, so they had to be added for differentiation

The following have been tested:
- CRMF auto enroll
- CRMF manual enroll/approval
- CMC-CRMF enroll
- both CA and KRA internal ldap are examined for correct data exclusion

Note: CRMF could potentially not include key archival option, however, I am not going to differentiate them at the moment.  An earlier prototype I had built attempted to do that and the signing cert's record isn't excluded for attrs write while it's CRMF request is the same as that of its encryption cert counterpart within the same request.  Due to this factor (multiple cert reqs with the same request blob), I am treating them the same for exclusion.

pushed to master

commit 62d8908d91e74320db647b939c0d9900c09d0608
Author: Christina Fu cfu@redhat.com
Date: Fri Jun 17 14:48:17 2016 -0700

Ticket #2298 Part3- trim down debug log in non-TMS crmf enrollments

Metadata Update from @cfu:
- Issue assigned to cfu
- Issue set to the milestone: 10.3.3

7 years ago

Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new
issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.

This issue has been cloned to GitHub and is available here:
https://github.com/dogtagpki/pki/issues/2418

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.

Login to comment on this ticket.

Metadata