updates.
authorPekka Riikonen <priikone@silcnet.org>
Wed, 31 Oct 2001 19:56:02 +0000 (19:56 +0000)
committerPekka Riikonen <priikone@silcnet.org>
Wed, 31 Oct 2001 19:56:02 +0000 (19:56 +0000)
CHANGES
README
doc/draft-riikonen-silc-commands-02.nroff
doc/draft-riikonen-silc-ke-auth-04.nroff

diff --git a/CHANGES b/CHANGES
index c09573b63670098dde26a5935f414138055cc447..55e832beed651cd9247040d583eb46e5bf463ed4 100644 (file)
--- a/CHANGES
+++ b/CHANGES
@@ -1,3 +1,9 @@
+Tue Oct 30 22:48:59 EST 2001  Pekka Riikonen <priikone@silcnet.org>
+
+       * Assure that silc_server_close_connection cannot be called
+         twice for same socket context.  Affected file is
+         silcd/server.c.
+
 Tue Oct 30 16:58:14 EST 2001  Pekka Riikonen <priikone@silcnet.org>
 
        * Send error message to application if opening file for
diff --git a/README b/README
index a1a3a9f0e8c553b4bbe1420e990d13317a21d481..2a946e5635c27a7795c85772e50576111ca519b9 100644 (file)
--- a/README
+++ b/README
@@ -3,7 +3,7 @@ SILC - Secure Internet Live Conferencing
 
 SILC (Secure Internet Live Conferencing) is a protocol which provides
 secure conferencing services in the Internet over insecure channel.
-SILC is IRC like softwarre although internally they are very different.
+SILC is IRC like software although internally they are very different.
 Biggest similarity between SILC and IRC is that they both provide
 conferencing services and that SILC has almost same commands as IRC.  Other
 than that they are nothing alike.  Biggest differences are that SILC is 
index ac17d89c3828c0f2673cb071d7c59ea8d56b11bd..3b3d7d5534b124c04d81144c4f0c8bc762a65d68 100644 (file)
@@ -259,12 +259,13 @@ List of all defined commands in SILC follows.
 
         Reply messages to the command:
 
-        Max Arguments:  8
+        Max Arguments:  9
             Arguments:  (1) <Status Payload>       (2) <Client ID> 
                         (3) <nickname>[@<server>]  (4) <username@host> 
                         (5) <real name>            (6) [<Channel Payload 
                                                          list>] 
                         (7) [<user mode>]          (8) [<idle time>]
+                        (9) [<fingerprint>]
 
 
         This command may reply with several command reply messages to
@@ -281,12 +282,19 @@ List of all defined commands in SILC follows.
         <count> option were defined in the query there will be only
         <count> many replies from the server.
 
-        The server MAY return the list of channel the client has joined.
+        The server may return the list of channel the client has joined.
         In this case the list is list of Channel Payloads.  The Mode Mask
         in the Channel Payload (see [SILC2] and section 2.3.2.3 for the
         Channel Payload) is the client's mode on the channel.  The list
         is encoded by adding the Channel Payloads one after the other.
 
+        The server may also send client's user mode, idle time, and the
+        fingerprint of the client's public key.  The <fingerprint> is the
+        binary hash digest of the public key.  The fingerprint MUST NOT
+        be sent if the server has not verified the proof of posession of
+        the corresponding private key.  Server can do this during the
+        SILC Key Exchange protocol.
+
         Status messages:
 
             SILC_STATUS_OK
index 315a91ba6d5f85ad7e7b088b23127e09463bd8dc..585479bcc5a660a10f34f7c1daeca198bb385a00 100644 (file)
@@ -406,9 +406,9 @@ two SILC clients.  In normal case, where client is connecting to a
 server, or server is connecting to a router the Mutual Authentication
 flag may be omitted.  However, if the connection authentication protocol 
 for the connecting entity is not based on public key authentication (it
-is based on passphrase) then it is RECOMMENDED that Mutual Authentication 
-flag is enabled.  This way the connecting entity has to provide proof
-of posession of the private key for the public key it will provide in
+is based on passphrase) then the Mutual Authentication flag SHOULD be 
+enabled.  This way the connecting entity has to provide proof of
+posession of the private key for the public key it will provide in
 SILC Key Exchange protocol.
 
 When performing re-key with PFS selected this is the only payload that