<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 08/01/2012 09:19 PM, Maru Newby wrote:
    <blockquote
      cite="mid:71BD4F07-1B97-46E4-BF67-08BB8B765A5B@internap.com"
      type="cite">I see that support for PKI Signed Tokens has been
      added to Keystone without support for token revocation.  I tried
      to raise this issue on the bug report:
      <div><br>
      </div>
      <div><a moz-do-not-send="true"
          href="https://bugs.launchpad.net/keystone/+bug/1003962/comments/4">https://bugs.launchpad.net/keystone/+bug/1003962/comments/4</a></div>
      <div><br>
      </div>
      <div>And the review:</div>
      <div><br>
      </div>
      <div><a moz-do-not-send="true"
          href="https://review.openstack.org/#/c/7754/">https://review.openstack.org/#/c/7754/</a></div>
      <div><br>
      </div>
      <div>I'm curious as to whether anybody shares my concern and if
        there is a specific reason why nobody responded to my question
        as to why revocation is not required for this new token scheme.
          Anybody?</div>
    </blockquote>
    <br>
    It was discussed back when I wrote the Blueprint.  While it is
    possible to do revocations with PKI,  it is expensive and requires a
    lot of extra checking.  Revocation is a policy decision, and the
    assumption is that people that are going to use PKI tokens are
    comfortable with out revocation.  Kerberos service tickets have the
    same limitation, and Kerberos has been in deployment that way for
    close to 25 years.<br>
    <br>
    Assuming that PKI ticket lifespan is short enough,  revocation
    should not be required.  What will be tricky is to balance the needs
    of long lived tokens (delayed operations, long running operations)
    against the needs for reasonable token timeout.<br>
    <br>
    PKI Token revocation would look like CRLs in the Certificate world. 
    While they are used, they are clunky.  Each time a token gets
    revoked, a blast message would have to go out to all registered
    parties informing them of the revocation.  Keystone does not yet
    have a message queue interface, so doing that is prohibitive in the
    first implementation.<br>
    <br>
    Note that users can get disabled, and token chaining will no longer
    work:  you won't be able to use a token to get a new token from
    Keystone.<br>
    <br>
    <br>
    <blockquote
      cite="mid:71BD4F07-1B97-46E4-BF67-08BB8B765A5B@internap.com"
      type="cite">
      <div><br>
      </div>
      <div>Thanks,</div>
      <div><br>
      </div>
      <div><br>
      </div>
      <div>Maru</div>
      <div><br>
        <div><br>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Mailing list: <a class="moz-txt-link-freetext" href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a>
Post to     : <a class="moz-txt-link-abbreviated" href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>
Unsubscribe : <a class="moz-txt-link-freetext" href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a>
More help   : <a class="moz-txt-link-freetext" href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>