[Webfunds-commits] java/webfunds TODO_SCW
Ian Grigg
iang@cypherpunks.ai
Wed, 16 Aug 2000 14:44:19 -0400 (AST)
iang 00/08/16 14:44:19
Modified: webfunds TODO_SCW
Log:
status as of now
Revision Changes Path
1.2 +74 -46 java/webfunds/TODO_SCW
Index: TODO_SCW
===================================================================
RCS file: /home/webfunds/cvsroot/java/webfunds/TODO_SCW,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TODO_SCW 2000/08/14 21:30:23 1.1
+++ TODO_SCW 2000/08/16 18:44:19 1.2
@@ -2,67 +2,95 @@
I. Sanity checking is needed:
- I.a) Contract - all these can be repaired and saved on the fly
+ (* that these are all potential checks may be also conducted within
+ Contract.verify, now called in FinishSig after Signing. But, earlier
+ checks would be good too.)
+
+ I.a) Contract - all these can be repaired and saved on the fly
+
+ + no trailing spaces
+ + uniform line endings
+ + all lines shorter or equal to 80 chars
+ + 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...
+
+ I.b) PKI
+
+ * top level signs contract signing key (and itself)
+ * contract signing key signs itself (and the contract, I.d below)
+ * server key only signs itself
+ * keys have userIdTag strings: { "[contract]" "[cert]" "[server]" }
+ as defined in
+ http://www.systemics.com/docs/ricardo/issuer/contract.html
+
+ I.c) Secret Key
+
+ + secret key matches contract public key
+ + 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.)
+
+ - now picks up dud passphrase but takes about 30 seconds the
+ first time to find out... Must be SecureRandom?
+
+ I.d) Signed Contract
+
+ * signature made is correct and verifiable with contents of contract
+ + no additional chars introduced, strip sig and keys and diff with
+ initial prototype contract.
- * no trailing spaces
- * uniform line endings
- * all lines shorter or equal to 80 chars
- * Ricardian rules - sections, etc.
- n.b. in http://www.systemics.com/docs/ricardo/issuer/contract.html
-
- I.b) PKI
-
- * top level signs contract (and itself ?)
- * contract signs itself (?)
- * server key?
-
- I.c) Secret Key
-
- * secret key matches contract public key
- * secret key decrypts properly
-
- I.d) Signed Contract
-
- * signature made is correct and verifiable with contents of contract
- * no additional chars introduced, strip sig and keys and diff with
- initial prototype contract.
-
II. Presentation.
- * Contract should be written out in local format
- (with platform line ending, currently has ^M on Unix).
+ Some of the notes assume that the concept of "Wizard" is modifiable,
+ (as discussed...) which may be a bad assumption.
- * no title bar on window, something like Sign Contract Wizard
- hard coded would be good.
+ a. Contract should be written out in local format
+ (with platform line ending, currently has ^M on Unix).
-=============8<==================8<==================8<======
+ b. no title bar on window, something like Sign Contract Wizard
+ hard coded would be good.
+ c.1 Browse starts in home directory not current directory?
-1. Contract: Read File - does not describe state of contract, which must
- be clean of PGP cruft, all from [keys] inclusive should be
- deleted manually.
+ c.2 file names - asks for a file name for keys, but it must be
+ an absolute file name, not a relative file name from current
+ directory. It would be preferable it if it could default to
+ to current directory if the filename did not start with the
+ pathname separator (some System. thing string that has / in it).
-1.a Browse starts in home directory not current directory?
+ d.1 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.
-1.b Needs a save button to save out that file to the original
- Name or a browsed name. Need to recall the name.
+ d.2 Needs a save button to save out that file to the original
+ Name or a browsed name. Need to recall the name.
-1.c Edit box ... no sanity checking.
+ d.3 Contract: Read File - does not describe state of contract, which must
+ be clean of PGP cruft, all from [keys] inclusive should be
+ deleted manually.
+
+ (Needs more support from Contract to do this checking as Contract.java
+ can only read a signed Contract.)
-1.d Did we agree on a file format naming system? TLA extensions?
+ d.4 better yet, it should use these as a starting point for the keys.
-2. Keys. C&P box for keys would be nice...
+ e. Keys. C&P box for keys would be nice...
-2.a Instructions for GPG would also be useful!
+ f. Did we agree on a file format naming system? TLA extensions?
-3. no confirmation from Toplevel (or any Key box) that the key was good?
+ g. Instructions for GPG would also be useful!
-4. ... specify FILE NAME of where FILE contract is stored...
+ h. instructions: ... specify FILE NAME of where FILE contract is stored...
-5. Signing ... some indication as to time expected,
- and is working.
+ i. Info: add (Plugins / ContractBrowser) after
+ "whether it accepts the contract ()"
-5.a where does it ask for the decryption key on signing???
+III. Coding comments (minor).
-6 Info: add (Plugins / ContractBrowser) after "whether it
- accepts the contract ()"
+ + should have some manifest constant "eoln = "\r\n" for
+ better readability? See II.1st above.