test-example: all-privkeys: Define, and indirect through, a variable

[secnet.git] / NOTES

diff --git a/NOTES b/NOTES
index ca8c04ac70f0092fd32cd41e1cc4477686279f66..a681d75f231cb21c0e6b316ee12e77444907bdd9 100644 (file)
--- a/NOTES
+++ b/NOTES
@@ -188,9 +188,10 @@ When deciding which public keys to accept, a relier should:
 
 In configuration and key management, long-term private and public keys
 are octet strings.  Private keys are generally stored in disk files,
-one key per file.  The octet string for a private key must identify
-the algorithm (although actually this is wrong and are going to change
-it later)..  The octet string for a public key need not identify the
+one key per file.  The octet string for a private key should identify
+the algorithm so that passing the private key to the code for the 
+wrong algorithm does not produce results which would leak or weaken
+the key.  The octet string for a public key need not identify the
 algorithm; when it's loaded the algorithm will be known from context.
 
 The group id 00000000 is special.  It should contain only one key,
@@ -268,6 +269,12 @@ initial subset of the following list of items:
    abilities of the sender.
  * In MSG3/MSG4: a 16-bit integer being the sender's MTU, or zero.
    (In other messages: nothing.)  See below.
+ * In MSG2/MSG3: a list of the peer's public keys that the sender will
+   accept: (i) a 1-byte integer count (ii) that many 5-byte key ids.
+   If not present, implicitly only the special key id 0000000000.
+ * In MSG3/MSG4: an 8-bit integer being an index into the
+   receiver's public key acceptance list, with which the message
+   is signed.  If not present, implicitly the key id 00000000000.
  * More data which is yet to be defined and which must be ignored
    by receivers.
 The optional additional data after the receiver's name is not