Update for the current state of the world, remove some stuff that we

aren't going to do, and flesh out some of the thoughts.

1 files changed, 47 insertions, 36 deletions

diff --git a/docs/notes b/docs/notes
index a51e19e..6a85b5a 100644
--- a/docs/notes
+++ b/docs/notes
@@ -5,9 +5,12 @@ Introduction
     Collected here are implementation notes about design decisions,
     external interfaces, integration, internal structure, and related
     issues.  This document will mostly be of interest to people who want
-    to modify the wallet code or who are curious about its design.  This
-    is not user documentation or protocol specifications; see elsewhere
-    for that.
+    to modify the wallet code or who are curious about its design.
+
+    This is now mostly of historical interest.  For information about how
+    the wallet now works, see the documentation for each of the server
+    classes, the other design documents, and the man pages for the
+    programs.
 
 Server Issues
 
@@ -25,8 +28,8 @@ Server Issues
       Generates a new keytab normally, but retrieves the existing keytab
       if we've marked the key as unchanging.
 
-    flag unchanging
-    flag -unchanging
+    flag set unchanging
+    flag clear unchanging
 
       Change the state to generate new keytabs each time or always try to
       pull the existing key.  This operation should probably be
@@ -42,26 +45,29 @@ Server Issues
 
   ACL Management
 
-    Supported operations are:  get, store, create (triggered by a get or
-    store of something that didn't already exist), destroy, show, and
-    setting or clearing flags.  Each of these need a separate ACL
+    Supported operations are:  get, store, create (possibly triggered by a
+    get or store of something that didn't already exist), destroy, show,
+    and setting or clearing flags.  Each of these need a separate ACL
     potentially.  Not sure if we're going to need separate ACLs for each
     flag operation.
 
-    Administrators get implicit access to do anything.  There does need to
-    be an ACL on create, but that should probably be implemented per
-    backend class (keytabs and certs will use NetDB roles, files will use
-    some namespace limitation based on a separate table, etc.).  There may
-    also need to be a class-specific fallback when no ACL is set to deal
-    with, for instance, ACL management via NetDB roles for systems that
-    have no more specific ACL.
+    Administrators get implicit access to do anything except get and
+    store.  They can give themselves get and store access just by changing
+    ACLs, of course, but it encourages sloppy ACLs to let them get and
+    store without an explicit ACL (administrators then end up relying on
+    that privilege and not reflecting it in ACLs).  There does need to be
+    an ACL on create, but that should probably be implemented via some
+    sort of policy callout.  The user will write a simple Perl function
+    that returns a default ACL given the object type and name if the
+    object doesn't already exist.
 
     Owner rights provides get, store, and show, but not destroy or setting
     or clearing flags (not destroy because it's too destructive and we
     don't want it done accidentally).  This can be overridden by more
     precise ACL settings.  So the ACL logic would go like this:
 
-     * If the user is an administrator, operation is permitted.
+     * If the user is an administrator and the operation isn't get or
+       store, operation is permitted.
 
      * Otherwise, check the object.  If it exists and has a setting for
        that specific ACL, apply that ACL.
@@ -69,23 +75,13 @@ Server Issues
      * If the object exists but with no specific ACL setting and the
        operation is one of get, store, or show, apply the owner ACL.
 
-     * If there is no listed owner ACL, punt to the backend and see if it
-       can apply a default ACL.
-
-     * If the object doesn't exist, punt to the backend, which will do its
-       own ACL check against backend-specific rules.
+     * If the object doesn't exist and the action is get, store, or
+       create, punt to a local policy if it exists and see if it returns a
+       default ACL.
 
     I think the owner abstraction is worth it over just setting the ACL
     for get, store, and show.
 
-    We also need to provide an interface to manage certain types of ACLs,
-    in particular the krb5-group ACL scheme, at least in the short term
-    until we standardize on using LDAP for all of those ACLs.  We're
-    probably going to continue to use krb5-group ACLs for the forseeable
-    future in at least some cases, since we'll want to be able to do
-    things when LDAP or AFS is down or we'll want a higher level of
-    security than either can ensure.
-
   Flags
 
     locked      --  No operations permitted except show
@@ -94,7 +90,9 @@ Server Issues
     For backends like secure files, all values are unchanging implicitly,
     but I don't think we should represent this by setting flags on every
     instance of those backends; it's just confusing and doesn't provide
-    more information.
+    more information.  In other words, unchanging is only meaningful for
+    backends that normally dynamically generate new keys on get, like the
+    keytab backend.
 
   Expiration
 
@@ -106,6 +104,10 @@ Server Issues
     that take the object name and the expiration date.  This would be
     great for certificates, for instance.
 
+    Not clear whether every get and store should check the expiration or
+    just a nightly cron job that blows away or locks objects when they
+    pass their expiration.
+
   Keytab Backend
 
     As of the deployment of the wallet, we want to stop limiting nearly
@@ -140,9 +142,16 @@ Server Issues
     anything with (except ideally it's associated with a certificate),
     there's the CSR (which we could reuse for renewals although that
     doesn't get people to change their key), and there's the certificate
-    itself (which is actually public data).  Should there be some method
-    for someone to request that their previous CSR be reused to request a
-    new Comodo certificate?  Maybe more work than needed.
+    itself (which is actually public data).
+
+    People seem to like to have CSRs kept around, but I don't understand
+    why and need to investigate this further.  It makes more sense to me
+    to generate a new key every time the cert is renewed, for additional
+    security.
+
+    We may be able to just store a file that contains both the key and the
+    public certificate and change our practices on web server
+    configuration to point them at the combined file.
 
   Cleanup of Old Entries
 
@@ -150,7 +159,8 @@ Server Issues
     that aren't in NetDB.  Rather than removing them immediately, wait
     until we haven't seen the host for several consecutive passes and then
     purge them.  Send notification of the hosts that are being purged (and
-    maybe of the hosts that will be purged soon if nothing happens).
+    maybe of the hosts that will be purged soon if nothing happens),
+    although that raises the question of where to send the notification.
 
 Client Issues
 
@@ -162,8 +172,9 @@ Client Issues
     write the key, and will need an optional flag specifying the time
     delta at which old kvnos should be pruned from the keytab.  These
     flags need to be globally unique in the wallet client so that we can
-    use a naive option parser, although at least for starters we'll
-    probably require that all the options be given after the operation.
+    use a naive option parser.  It would also be nice to support the flags
+    anywhere in the command and not go down the weird CVS route of flags
+    meaning different things in different places.
 
   Keytab Handling