logging: site: Log state on PHASE_RUN entry instead of initially

[secnet.git] / NOTES

diff --git a/NOTES b/NOTES
index ca8c04ac70f0092fd32cd41e1cc4477686279f66..001c118e96f9401592560ea3332583b653ac2c55 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,
 
 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,
 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.
    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
  * 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,
 
 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
 
 Currently, the low 16 bits are allocated for negotiating bulk-crypto
 transforms.  Bits 8 to 15 are used by Secnet as default capability