X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=NOTES;h=001c118e96f9401592560ea3332583b653ac2c55;hb=564022994befb8f71b89ae015751b22c34ae3ee8;hp=ca8c04ac70f0092fd32cd41e1cc4477686279f66;hpb=1357497b8a66bf595f04129403ea326b975e59d5;p=secnet.git

diff --git a/NOTES b/NOTES
index ca8c04a..001c118 100644
--- 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
@@ -277,14 +284,11 @@ Capability flag bits must be in one the following two categories:
 
 1. Early capability flags must be advertised in MSG1 or MSG2, as
    applicable.  If MSG3 or MSG4 advertise any "early" capability bits,
-   MSG1 or MSG3 (as applicable) must have advertised them too.  Sadly,
-   advertising an early capability flag will produce MSG1s which are
-   not understood by versions of secnet which predate the capability
-   mechanism.
-
-2. Late capability flags are advertised in MSG2 or MSG3, as
-   applicable.  They may also appear in MSG1, but this is not
-   guaranteed.  MSG4 must advertise the same set as MSG2.
+   MSG1 or MSG3 (as applicable) must have advertised them too.
+
+2. Late capability flags may be advertised only in MSG2 or MSG3, as
+   applicable.  They are only in MSG1 with newer secnets; older
+   versions omit them.  MSG4 must advertise the same set as MSG2.
 
 Currently, the low 16 bits are allocated for negotiating bulk-crypto
 transforms.  Bits 8 to 15 are used by Secnet as default capability