updates.
[silc.git] / doc / draft-riikonen-silc-spec-02.nroff
index 6c6f800d6eba1df6f6ba77d8bcee57a3b17e8037..0cf79690e4d94e6814a58692a09141fd40157858 100644 (file)
@@ -1777,7 +1777,8 @@ process.
 
 Session keys should be regenerated periodically, say, once in an hour.
 The re-key process is started by sending SILC_PACKET_REKEY packet to
-other end, to indicate that re-key must be performed.
+other end, to indicate that re-key must be performed.  The initiator
+of the connection should perform the re-key.
 
 If perfect forward secrecy (PFS) flag was selected in the SILC Key
 Exchange protocol [SILC3] the re-key must cause new key exchange with
@@ -1786,15 +1787,26 @@ and the protocol results to new key material.  See [SILC3] for more
 information.  After the SILC_PACKET_REKEY packet is sent the sender
 will perform the SKE protocol.
 
+If PFS flag was set the resulted key material is processed as described
+in the section Processing the Key Material in [SILC3].  The difference
+with re-key in the processing is that the initial data for the hash 
+function is just the resulted key material and not the HASH as it
+is not computed at all with re-key.  Other than that, the key processing
+it equivalent to normal SKE negotiation.
+
 If PFS flag was not set, which is the default case, then re-key is done
 without executing SKE protocol.  In this case, the new key is created by
-hashing the old key with hash function selected earlier in the SKE
-protocol.  If the digest length of the hash function is too short for the
-key, then the key is distributed as described in section Processing the
-Key Material in [SILC3].  After both parties has regenerated the session
-key, both send SILC_PACKET_REKEY_DONE packet to each other.  These packets
-are still secured with the old key.  After these packets, the following
-packets must be protected with the new key.
+providing the current sending encryption key to the SKE protocol's key
+processing function.  The process is described in the section Processing
+the Key Material in [SILC3].  The difference in the processing is that
+the initial data for the hash function is the current sending encryption
+key and not the SKE's KEY and HASH values.  Other than that, the key
+processing is equivalent to normal SKE negotiation.
+
+After both parties has regenerated the session key, both send
+SILC_PACKET_REKEY_DONE packet to each other.  These packets are still
+secured with the old key.  After these packets, the subsequent packets
+must be protected with the new key.
 
 
 .ti 0
@@ -3226,6 +3238,34 @@ List of all defined commands in SILC follows.
             SILC_STATUS_ERR_NOT_ON_CHANNEL
 
 
+   26   SILC_COMMAND_GETKEY
+
+        Max Arguments:  1
+            Arguments:  (1) <ID Payload>
+
+        This command is used to fetch the public key of the client or
+        server indicated by the <ID Payload>.  The public key is fetched
+        from the server where to the client is connected.
+
+        Reply messages to the command:
+
+        Max Arguments:  3
+            Arguments:  (1) <Status Payload>      (2) <ID Payload>
+                        (3) <Public Key Payload>
+
+        This command replies with the client's or server's ID and with
+        the <Public Key Payload>.
+
+        Status messages:
+
+            SILC_STATUS_OK
+            SILC_STATUS_ERR_NOT_REGISTERED
+            SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+            SILC_STATUS_ERR_TOO_MANY_PARAMS
+            SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
+            SILC_STATUS_ERR_NO_SUCH_SERVER_ID
+
+
    27 - 199
 
         Currently undefined commands.
@@ -3503,6 +3543,11 @@ List of all defined command status messages following.
 
         "The algorithm was not supported."  The server does not support the
         requested algorithm.
+
+   47   SILC_STATUS_ERR_NO_SUCH_SERVER_ID
+
+        "No such Server ID".  Server ID provided does not exist.
+
 .in 3