Added SILC Thread Queue API
[crypto.git] / doc / draft-riikonen-silc-spec-03.nroff
index 19e8127c036354ed9c1a0a098da4c0e11ce3d09c..ecb58e4e291aea34ef053c96400afaafa7240069 100644 (file)
@@ -8,7 +8,7 @@
 .ds RF FORMFEED[Page %]
 .ds CF
 .ds LH Internet Draft
-.ds RH 22 July 2001
+.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                           22 July 2001
-Expires: 22 January 2002
+draft-riikonen-silc-spec-03.txt                         21 August 2001
+Expires: 21 February 2002
 
 .in 3
 
@@ -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
@@ -2016,10 +2032,6 @@ should have a forum to discuss the cell management issues.
              Requirement Levels", BCP 14, RFC 2119, March 1997.
 
 
-
-
-
-
 .ti 0
 7 Author's Address
 
@@ -2031,4 +2043,4 @@ Finland
 
 EMail: priikone@silcnet.org
 
-This Internet-Draft expires 22 January 2002
+This Internet-Draft expires 21 February 2002