[Webfunds-commits] java/webfunds TODO_SCW

Ian Grigg iang@cypherpunks.ai
Mon, 28 Aug 2000 12:31:13 -0400 (AST)


iang        00/08/28 12:31:12

  Modified:    webfunds TODO_SCW
  Log:
  removed DONE parts, reorganised a little.

Revision  Changes    Path
1.11      +24 -84    java/webfunds/TODO_SCW

Index: TODO_SCW
===================================================================
RCS file: /home/webfunds/cvsroot/java/webfunds/TODO_SCW,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- TODO_SCW	2000/08/28 16:14:24	1.10
+++ TODO_SCW	2000/08/28 16:31:12	1.11
@@ -2,85 +2,15 @@
 
 I.  Sanity checking that is needed:
 
-      I.a)  Contract - all these can be repaired and saved on the fly
-
-        + no trailing spaces (stripped in verify)
-          (DONE)
-
-        + uniform line endings.  NB, the Contract code _rejects_
-          _mixed_ line endings (for example \n followed by \r\n)
-          (DONE, stripped all combinations)
-
-        + all lines shorter or equal to 80 chars (not currently enforced)
-        + Ricardian rules - sections, etc.
-
-        n.b. in http://www.systemics.com/docs/ricardo/issuer/contract.html
-        which may be out of date but can be updated...
-
-        Correct place for this should be in the Contract, but it
-        doesn't provide the support for that yet.
-    
-      I.b)  PKI
-    
-        * top level [cert] signs [contract] signing key (and itself)
-          (DONE)
-        * contract signing key signs itself (and the contract, I.d below)
-          (DONE)
-        * server key only signs itself
-          (DONE)
-        + additional sigs that may be on the key must be stripped from
-          the key at this point (there is no other convenient way to do
-          this!)
-          (DONE)
-        * keys have userIdTag strings: { "[contract]"  "[cert]"  "[operator]"  }
-          (DONE)
-
-          tags are documented in
-          http://www.systemics.com/docs/ricardo/issuer/server-manage.html
-    
       I.c) Secret Key
     
-        * secret key matches contract public key - would be nice to have a
+        + secret key matches contract public key - would be nice to have a
           check as it is being entered, currently it is checked only during
           the signing process.
-        * secret key decrypts properly
-          (DONE)
-        + for the secret key, wouldn't a popup box be better for the passphrase?
-          (one presumes this signals that the key is quickly decrypted, used,
-          then the decrypted version is disposed of quickly...  may not be the
-          case.)
 
-      I.d) Signed Contract
-    
-        * signature made is correct and verifiable with contents of contract
-          (DONE by verify, in fact this is the *only* place for it!)
 
-        + additional potential sanity check:  that the signed contract can
-          be un-signed and contents compared with original proto-contract to
-          ensure that no additional chars were introduced during the signing
-          process. (defer... might think about that...)
-
-  * signifies checks that are conducted within Contract.verify(),
-    now called in FinishSig.next() after act of contract signing.
-    BUT, earlier checking of these conditions would be good too.
-
-
 II. Presentation. 
 
-    a.  Contract should be written out in local format
-        (with platform line ending, currently has ^M on Unix).
-        (DONE)
-
-    b.  Contract: Read File - does not describe state of contract, which must
-        be clean of PGP cruft, all from [keys] inclusive should be
-        deleted manually.
-        (DONE)
-     
-    c.  Bug: from "server" dialog, with nothing in the key name field,
-        pressing "Previous" resulting in exception message "Please select
-        a key" before switching back to previous screen.
-        (DONE by rewrite)
-
 III.  Coding comments (minor).
 
     + should have some manifest constant "eoln = "\r\n" for
@@ -94,6 +24,7 @@
       OpenPGP standard (99%) newline for cleartext sigs, also used
       (100%) by Ricardo for hashes.)
 
+
 IV.  Feature Requests!
 
     i)  Different methods for accessing keys.
@@ -118,18 +49,27 @@
            reaches a "confidence" level.
 
        d.  Binary keys as well as armoured keys.
+
+    ii) for the secret key, wouldn't a popup box be better for the passphrase?
+        (one presumes this signals that the key is quickly decrypted, used,
+        then the decrypted version is disposed of quickly...  may not be the
+        case.)
+
+    iv) additional potential sanity check:  that the signed contract can
+        be un-signed and contents compared with original proto-contract to
+        ensure that no additional chars were introduced during the signing
+        process. (defer... might think about that...)
+
+V.  For WebFunds.Ricardian
+
+      I.a)  Contract - all these can be repaired and saved on the fly
 
-    ii) desperately need to save context somehow by either saving each
-        dialog contents out (messy) or by saving the contract fully out
-        and sucking the keys from there.  Testing cycle takes too long
-        otherwise, as have to type in all the info each time.
-
-        Problem with this is that it is a major new piece of work, so
-        desperation means nothing against lack of resource....
-
-        "Ideal" way to do this is to firstly have save of contract
-        facilities (with keys appended) and secondly, to use keys
-        saved in (proto)contracts read in "Read File" as the keys
-        for later steps.
+        + all lines shorter or equal to 80 chars (not currently enforced)
+        + Ricardian rules - sections, etc.
+
+        n.b. in http://www.systemics.com/docs/ricardo/issuer/contract.html
+        which may be out of date but can be updated...
 
-        (DONE!)
+        Correct place for this should be in the Contract, but it
+        doesn't provide the support for that yet.
+