Document the requirements for the keytab backend.

2 files changed, 44 insertions, 2 deletions

diff --git a/doc/design-schema b/doc/design-schema
index 924196f..c82c387 100644
--- a/doc/design-schema
+++ b/doc/design-schema
@@ -93,3 +93,20 @@ ACL Backend Data
          (km_group              varchar(255)
               not null references krb5_groups(kg_name),
           km_principal          varchar(255) not null);
+
+Storage Backend Data
+
+    To support restricting the allowable enctypes for a given keytab, the
+    keytab backend will use the following table:
+
+      create table keytab_enctypes
+         (ke_principal          varchar(255)
+              not null references objects(ob_name),
+          ke_enctype            varchar(255)
+              not null references enctypes(en_name));
+
+    There is a normalization table to ensure that only supported enctypes
+    are configured:
+
+       create table enctypes
+          (en_name               varchar(255) primary key);
diff --git a/doc/notes b/doc/notes
index 3c0c25a..5f1633e 100644
--- a/doc/notes
+++ b/doc/notes
@@ -25,8 +25,8 @@ Server Issues
       Generates a new keytab normally, but retrieves the existing keytab
       if we've marked the key as unchanging.
 
-    mark unchanging
-    mark changing
+    flag unchanging
+    flag -unchanging
 
       Change the state to generate new keytabs each time or always try to
       pull the existing key.  This operation should probably be
@@ -106,6 +106,31 @@ Server Issues
     that take the object name and the expiration date.  This would be
     great for certificates, for instance.
 
+  Keytab Backend
+
+    As of the deployment of the wallet, we want to stop limiting nearly
+    all keytabs from being forced to single DES keys.  We're probably
+    still going to have some keys for which only particular enctypes are
+    permitted, however.  This means keeping a side table of allowable
+    enctypes per keytab name, where if there are no entries in the table
+    we allow any enctype.  We can pass a list of enctypes into kadmin when
+    doing the principal creation or randomization, separated by spaces and
+    enclosed in double quotes.
+
+    Whenever we generate a new keytab, we may need to push the key into
+    K4.  We could make the client send a flag saying whether they want
+    synchronization with K4, but it's easier to just always do it (except
+    maybe for some exception cases).  The user doesn't have to ask the
+    client program for the srvtab if they don't want it, and it doesn't
+    hurt to create the KDC entry.
+
+    This means that we need the gen_srvtab program from the old srvtab
+    backend on the server end to push the key into K4.  That program
+    already has the capability to take a srvtab containing the DES key and
+    push it into the K4 database.  It could probably stand some cleanup
+    and simplification for inclusion in the wallet source.  I'm probably
+    going to rename it to k4changekey or something similar in the process.
+
   Certificate Creation
 
     We probably want to handle all requested certificates from Comodo