<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Thanks for Jack's sharp eye, i accidentally messed up the git wit
    one new profile.  This new patch <br>
    1. fixed the git issue<br>
    2. change the CS.cfg config names to not include "ca" as they apply
    to kra too<br>
    3. Also after discussing with Jack, we decided to change the default
    of excludedLdapAttrs.enabled to false.<br>
    <br>
    thanks,<br>
    Christina<br>
    <br>
    <div class="moz-cite-prefix">On 06/16/2016 03:50 PM, Christina Fu
      wrote:<br>
    </div>
    <blockquote cite="mid:57632D48.6060200@redhat.com" type="cite">This
      is part 2 of:
      <br>
      <a class="moz-txt-link-freetext" href="https://fedorahosted.org/pki/ticket/2298">https://fedorahosted.org/pki/ticket/2298</a> [non-TMS] for key
      archival/recovery, not to record certain data in ldap and logs
      <br>
      <br>
      This patch allows one to exclude certain ldap attributes from the
      enrollment records for crmf requests
      <br>
      (both CRMF, and CMC CRMF).  The following are the highlights:
      <br>
      * CRMF Manual approval profile is disabled: caDualCert.cfg
      <br>
        - By default, if ca.excludedLDAPattrs.enabled is true, then this
      profile will not work, as the crmf requests
      <br>
          are not written to ldap record for agents to act on
      <br>
      * ca.excludedLDAPattrs.attrs can be used to configure the
      attribute list to be excluded
      <br>
      * a new CRMF "auto approval" (directory based, needs to be setup)
      is provided
      <br>
      * By default, the following fields are no longer written to the
      ldap record in case of CRMF:
      <br>
      (note: the code deliberately use literal strings on purpose for
      the reason that the exact literal strings need to be spelled out
      <br>
      in ca.excludedLDAPattrs.attrs if the admin chooses to override the
      default)
      <br>
                 "req_x509info",
      <br>
                 "publickey",
      <br>
                  "req_extensions",
      <br>
                  "cert_request",
      <br>
                  "req_archive_options",
      <br>
                  "req_key"
      <br>
      * a sleepOneMinute() method is added for debugging purpose.  It is
      not called in the final code, but is left there for future
      debugging purpose
      <br>
      * code was fixed so that in KRA request will display subject name
      even though the x509info is missing from request
      <br>
      * cmc requests did not have request type in records, so they had
      to be added for differentiation
      <br>
      <br>
      The following have been tested:
      <br>
      * CRMF auto enroll
      <br>
      * CRMF manual enroll/approval
      <br>
      * CMC-CRMF enroll
      <br>
      *  both CA and KRA interla ldap are exampled for correct data
      exclusion
      <br>
      <br>
      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.
      <br>
      <br>
      thanks,
      <br>
      Christina
      <br>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Pki-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Pki-devel@redhat.com">Pki-devel@redhat.com</a>
<a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pki-devel">https://www.redhat.com/mailman/listinfo/pki-devel</a></pre>
    </blockquote>
    <br>
  </body>
</html>