X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=NOTES;h=001c118e96f9401592560ea3332583b653ac2c55;hb=147b444d6faa9a621e33d653b7a72c29724203c3;hp=884ae303860fa72824d50da21ab08f3a22e247fa;hpb=4ab0e4ad32e169bfd9e3af465e5850ccb8520890;p=secnet.git diff --git a/NOTES b/NOTES index 884ae30..001c118 100644 --- a/NOTES +++ b/NOTES @@ -140,6 +140,75 @@ before going to background. 'normal' and 'failed' runs output to stdout/stderr before backgrounding, then thereafter output only to log destinations. +** Site long-term keys + +We use authenticated DH. Sites identify themselves to each other +using long-term signing keys. + +These signing keys may be for a variety of algorithms. (An algorithm +specifies completely how to do a signature and verification.) + +Each site may have several keys. This helps support key rollover and +algorithm agility. Several keys of different algorithms can form a +key group. Usually a key group consists of keys generated at the same +time. A key is identified by a 4-byte group id (invented by its +publisher and opaque) plus a 1-byte algorithm id (defined by the +protocol spec for each algorithm). + +Keys are published in key sets. A key set is a collection of key +groups (including older keys as well as newer ones) published at a +particular time. Key sets have their own 4-byte ids; these are +invented by the publisher but are ordered using sequence number +arithmetic. This allows reliers to favour new sets over old ones. + +Within each key set, some groups may be marked as `fallback'. This +means a group that should be tolerated by a relier only if the relier +doesn't support any non-fallback keys. + +Keys within groups, and groups within sets, are ordered (by the +publisher of the set), from most to least preferred. + +When deciding which public keys to accept, a relier should: + Process each group within the key set. + Discard unknown algorithms. + Choose a preferred algorithm: + Earliest in the group + (or local config could have algorithm prefererence). + Discard empty groups. + Discard unneeded fallback groups: + If any (non-empty) non-fallback groups found, discard all + fallback groups. Otherwise there are only fallback groups; + discard all but first group in the set. + Discard any keys exceeding limit on number of keys honoured: + Limit is at least 4 + Discard keys later in the set + In wire protocol, offer the resulting subset of keyids to + the peer and a allow the signer to select which key to use + from that subset. + +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 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 00. Key 0000000000 refers to the rsa1 key promulgated +before the key rollover/advertisement protocols, or the key which +should be used by sites running old software. + +The key set id 00000000 is special and is considered older than all +othere key sets (ie this is an exception to the sequence number +arithmetic). It is the implied key set id of the rsa1 key +promulgated before the key rollover/advertisement protocols. + +The algorithm 00 is special and refers to the old rsa1 signature +protocol but unusually does not identify the hash function. The hash +function is conventional and must be specified out of band. In known +existing installations it is SHA-1. + ** Protocols *** Protocol environment: @@ -200,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 @@ -209,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