[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.
+