Added SILC Thread Queue API

[crypto.git] / doc / draft-riikonen-silc-spec-03.nroff

diff --git a/doc/draft-riikonen-silc-spec-03.nroff b/doc/draft-riikonen-silc-spec-03.nroff
index e19be08c3b98618c779534c1f5a116443a5a72e2..ecb58e4e291aea34ef053c96400afaafa7240069 100644 (file)
--- a/doc/draft-riikonen-silc-spec-03.nroff
+++ b/doc/draft-riikonen-silc-spec-03.nroff
@@ -8,7 +8,7 @@
 .ds RF FORMFEED[Page %]
 .ds CF
 .ds LH Internet Draft
-.ds RH XXX
+.ds RH 21 August 2001
 .ds CH
 .na
 .hy 0
@@ -16,8 +16,8 @@
 .nf
 Network Working Group                                      P. Riikonen
 Internet-Draft
-draft-riikonen-silc-spec-03.txt                                    XXX
-Expires: XXX
+draft-riikonen-silc-spec-03.txt                         21 August 2001
+Expires: 21 February 2002
 
 .in 3
 
@@ -124,7 +124,7 @@ Table of Contents
   4.10 Closing Connection ....................................... 37
 5 Security Considerations ....................................... 38
 6 References .................................................... 38
-7 Author's Address .............................................. 39
+7 Author's Address .............................................. 40
 
 
 
@@ -1945,6 +1945,22 @@ is required by the server and router administrator prior acceptance to
 the SILC Network.  The clients must be able to trust the servers they
 are using.
 
+It must also be noted that if the client requires absolute security by
+not trusting any of the servers or routers in the SILC Network, this can
+be accomplished by negotiating private keys outside the SILC Network,
+either using SKE or some other key negotiation protocol, or to use some
+other external means for distributing the keys.  This applies for all 
+messages, private messages and channel messages.  It is important to note
+that SILC, like any other security protocol is not full proof system and
+cannot secure from insecure environment; the SILC servers and routers could
+very well be compromised.  However, to provide acceptable level of security
+and usability for end user the protocol uses many times session keys or
+other keys generated by the servers to secure the messages.  If this is
+unacceptable for the client or end user, the private keys negotiatied 
+outside the SILC Network should always be used.  In the end it is always
+implementor's choice whether to negotiate private keys by default or
+whether to use the keys generated by the servers.
+
 It is also recommended that router operators in the SILC Network would
 form a joint forum to discuss the router and SILC Network management
 issues.  Also, router operators along with the cell's server operators
@@ -2021,10 +2037,10 @@ should have a forum to discuss the cell management issues.
 
 .nf
 Pekka Riikonen
-Kasarmikatu 11 A4
-70110 Kuopio
+Snellmanninkatu 34 A 15
+70100 Kuopio
 Finland
 
-EMail: priikone@poseidon.pspt.fi
+EMail: priikone@silcnet.org
 
-This Internet-Draft expires XXX
+This Internet-Draft expires 21 February 2002