<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    ACK with ticket filed or to be filed.<br>
    <br>
    Christina<br>
    <br>
    <div class="moz-cite-prefix">On 09/27/2013 05:15 PM, Andrew Wnuk
      wrote:<br>
    </div>
    <blockquote cite="mid:52461FB6.7070700@redhat.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <div class="moz-cite-prefix">On 09/27/2013 09:55 AM, Christina Fu
        wrote:<br>
      </div>
      <blockquote cite="mid:5245B86C.4060403@redhat.com" type="cite">
        <meta content="text/html; charset=ISO-8859-1"
          http-equiv="Content-Type">
        First of all, I think it's a nice framework that lays the basis
        for supporting multiple DRM transport keys.  Thanks for taking
        care of the encrypt/decrypt case as well, which is essential in
        DRM for supporting HSM's that do not support
        wrapping/unwrapping.<br>
        <br>
        A couple observations/questions:<br>
        <br>
        * in base/kra/src/com/netscape/kra/EnrollmentService.java,
        transportCert is specifically deleted from the requests after
        extraction.<br>
        We might want to consider making it optional.  I understand that
        some customer in the past has utilized DRM requests for their
        own purposes.  If space is a concern, one idea is to store the
        nickname instead.  Just something to think about.<br>
        <br>
        * Another thing, perhaps as a phase 2, is to think about how to
        get the exact transport cert that the client is using into the
        request to the DRM.  The primary scenario that we wish to cover,
        I think, is the case when the transport keys are in transition. 
        The scenario in my mind would be someone getting to the
        enrollment page (thus a transport key is already in the
        browser), then taking his/her time to fill out the form,
        meanwhile, the CA's transport cert changed.  However, in this
        patch, CA is getting the transport cert from it's CS.cfg and
        stuffing it into the request, which means that in this scenario,
        CA is stuffing the new transport cert into the request instead
        of the old one that the client is using. <br>
        Again, I understand that it is not an easy one to resolve, but
        it is essential to this feature so we need to solve eventually,
        perhaps at the next phase.  We can discuss more about this.<br>
      </blockquote>
      Ticket #750 has been created - <a moz-do-not-send="true"
        class="moz-txt-link-freetext"
        href="https://fedorahosted.org/pki/ticket/750">https://fedorahosted.org/pki/ticket/750</a><br>
      <blockquote cite="mid:5245B86C.4060403@redhat.com" type="cite"> <br>
        Christina<br>
        <br>
        <div class="moz-cite-prefix">On 09/25/2013 04:59 PM, Andrew Wnuk
          wrote:<br>
        </div>
        <blockquote cite="mid:524378F8.7040204@redhat.com" type="cite">   

          This patch provides basic support for DRM transport key
          rotation described <br>
              in <a moz-do-not-send="true"
            class="moz-txt-link-freetext"
            href="http://pki.fedoraproject.org/wiki/DRM_Transport_Key_Rotation">http://pki.fedoraproject.org/wiki/DRM_Transport_Key_Rotation</a>
          <br>
          <br>
              This patch provides implementation for tickets: <br>
               - 729 - CA to include transport certificate when
          submitting archival request to DRM <br>
               - 730 - DRM to detect presence of transport certificate
          attribute in submitted archival <br>
                       request and validate transport certificate
          against DRM's transport key list <br>
               - 731 - DRM to provide handling for alternative transport
          key based on detected <br>
                       and validated transport certificate arriving as a
          part of extended archival request <br>
          <br>
          <br>
          <br>
          <br>
          <fieldset class="mimeAttachmentHeader"></fieldset>
          <br>
          <pre wrap="">_______________________________________________
Pki-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Pki-devel@redhat.com">Pki-devel@redhat.com</a>
<a moz-do-not-send="true" 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>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
Pki-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Pki-devel@redhat.com">Pki-devel@redhat.com</a>
<a moz-do-not-send="true" 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>
      <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>