<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-text-flowed" style="font-family: -moz-fixed;
      font-size: 12px;" lang="x-western">I've gotten The PKI signed
      tokens code working,  although not ready for submission.  Still
      needs some cleanup.<br>
      <br>
      <br>
      <a class="moz-txt-link-freetext"
        href="https://github.com/admiyo/keystone/tree/signed-tokens-2">https://github.com/admiyo/keystone/tree/signed-tokens-2</a>
      <br>
      <br>
      Commit is here:
      <br>
      <br>
      <a class="moz-txt-link-freetext"
href="https://github.com/admiyo/keystone/commit/e566167f45d71f4e3e6cec7524e7097a86d68b80">https://github.com/admiyo/keystone/commit/e566167f45d71f4e3e6cec7524e7097a86d68b80</a>
      <br>
      <br>
      Feel free to provide line level comments.<br>
      <br>
      <br>
      Configuration is still a little wonky.  auth_token inherits the
      past Config from the service that calls it.  Thus,  sign and
      verify are hacked to use different conf systems.  I  don't think
      these config values should be in past,  but rather in the "good"
      config files for the various services.  I'd also like to provide
      decent defaults for them.
      <br>
      <br>
      Guang and Liem talked me out of trying to piggy back on the SSL
      config options, even though the CA certs will be the same, and the
      Signing keys can be the same.  We both agree that the certs should
      not be the same.  I can explain in depth why this is if anyone
      really cares.
      <br>
      <br>
      This puts a new dependency into the system:  The OpenSSL binary. 
      Fropm what I can tell,  the only safe way to call OpenSSL is from
      the POpen API,  as Eventlet wraps it.  This should work equally as
      well from HTTPD.  The signing is done without using any interim
      files or directories:  input and output are using the standard
      file descriptors.  I think this is an elegant solution.
      <br>
      <br>
      Rafaduran had a good point about memory usage for KVS.  Since the
      tokens will be roughly 10 times the size they were previously, 
      KVS might be too expensive.  An optimization in the future is to
      drop recording the tokens into a datastore,  and merely log them
      to an audit log.  Even Keystone can use the cryptographic approach
      to validate.
      <br>
      <br>
      I'm going to avoid putting in a revocation mechanism for the first
      approximation. I'll make sure that token time-out is a well
      documented config option, and we'll go with the shortest
      time-frame that we can for default expiry.<br>
      <br>
      <br>
    </div>
  </body>
</html>