.ds RF FORMFEED[Page %]
.ds CF
.ds LH Internet Draft
-.ds RH 15 May 2002
+.ds RH XXX
.ds CH
.na
.hy 0
.nf
Network Working Group P. Riikonen
Internet-Draft
-draft-riikonen-silc-spec-05.txt 15 May 2002
-Expires: 15 November 2002
+draft-riikonen-silc-spec-06.txt XXX
+Expires: XXX
.in 3
.ce 3
Secure Internet Live Conferencing (SILC),
Protocol Specification
-<draft-riikonen-silc-spec-05.txt>
+<draft-riikonen-silc-spec-06.txt>
.ti 0
Status of this Memo
represented as sign(). The signature computing procedure is dependent
of the public key algorithm, and the public key or certificate encoding.
When using SILC public key the signature is computed as described in
-previous section for RSA and DSS keys. When using SSH2 public keys
-the signature is computed as described in [SSH-TRANS]. When using
-X.509 version 3 certificates the signature is computed as described
-in [PKCS7]. When using OpenPGP certificates the signature is computed
-as described in [PGP].
+previous paragraph for RSA and DSS keys. If the hash function is not
+specified separately for signing process sha1 MUST be used. When using
+SSH2 public keys the signature is computed as described in [SSH-TRANS].
+When using X.509 version 3 certificates the signature is computed as
+described in [PKCS7]. When using OpenPGP certificates the signature is
+computed as described in [PGP].
.ti 0
All fields in the public key are in MSB (most significant byte first)
order. All strings in the public key are UTF-8 encoded.
+If an external protocol need to refer to SILC Public Key by name, the
+name "silc-rsa" and "silc-dss" for SILC Public Key based on RSA algorithm
+and SILC Public Key based on DSS algorithm, respectively, are to be used.
+However, this SILC specification does not use these names directly, and
+they are defined here for external protocols (protocols that may like
+to use SILC Public Key).
+
.ti 0
3.12 SILC Version Detection
Protocol version MAY provide both major and minor version. Currently
implementations MUST set the protocol version and accept at least the
-protocol version as SILC-1.1-<software version>. If new protocol version
+protocol version as SILC-1.2-<software version>. If new protocol version
causes incompatibilities with older version the <minor> version number
MUST be incremented. The <major> is incremented if new protocol version
is fully incompatible.
.in 6
SILC-1.1-2.0.2
SILC-1.0-1.2
-SILC-1.1-1.0.VendorXYZ
-SILC-1.1-2.4.5 Vendor Limited
+SILC-1.2-1.0.VendorXYZ
+SILC-1.2-2.4.5 Vendor Limited
.in 3
5. Backup router MUST wait for all packets with type value 3 before
it continues with the protocol. It knows from the session ID values
set in the packet when it have received all packets. The session
- value should be different in all packets it have send earlier.
+ value should be different in all packets it have sent earlier.
After the packets is received the backup router sends the
SILC_PACKET_RESUME_ROUTER packet with type value 4 to the
primary router that came back online. This packet will indicate
that the backup router is now ready to resign as being primary
router. The session ID value in this packet MUST be the same as
in first packet sent to the primary router. During this time
- the backup router should still route all packets it is receiving
+ the backup router must still route all packets it is receiving
from server connections.
6. The primary router receives the packet and send the
3 SILC_SERVER_BACKUP_START_CONNECTED
4 SILC_SERVER_BACKUP_START_ENDING
5 SILC_SERVER_BACKUP_START_RESUMED
- 6 SILC_SERVER_BACKUP_START_GLOBAL
+ 6 SILC_SERVER_BACKUP_START_RESUMED_GLOBAL
20 SILC_SERVER_BACKUP_START_REPLACED
If any other value is found in the type field the packet must be
All clients are announced by compiling a list of ID Payloads into the
SILC_PACKET_NEW_ID packet. All channels are announced by compiling a
-list of Channel Payloads into the SILC_PACKET_NEW_CHANNEL packet. Also,
-the channel users on the channels must be announced by compiling a
+list of Channel Payloads into the SILC_PACKET_NEW_CHANNEL packet.
+Channels' mode and founder public key and other channel mode specific
+data is announced by sending SILC_NOTIFY_TYPE_CMODE_CHANGE notify list.
+Also, the channel users on the channels must be announced by compiling a
list of Notify Payloads with the SILC_NOTIFY_TYPE_JOIN notify type into
the SILC_PACKET_NOTIFY packet. The users' modes on the channel must
also be announced by compiling list of Notify Payloads with the
The raw key data is the key data received in the Channel Key Payload.
The hash() function is the hash function used in the HMAC of the channel.
-Note that the server MUST also save the channel key.
+Note that the server also MUST save the channel key.
.ti 0
the key material SHOULD be processed as defined in the [SILC3]. In
the processing, however, the HASH, as defined in [SILC3] MUST be
ignored. After processing the key material it is employed as defined
-in [SILC3], however, the HMAC key material MUST be discarded.
+in [SILC3].
If the key is pre-shared-key or randomly generated the implementations
-SHOULD use the SILC protocol's mandatory cipher as the cipher. If the
-SKE was used to negotiate key material the cipher was negotiated as well,
-and may be different from default cipher.
+SHOULD use the SILC protocol's mandatory cipher as the cipher, and the
+mandatory HMAC as the HMAC. If the SKE was used to negotiate key material
+the cipher was negotiated as well, and may be different from default
+cipher and default HMAC.
.ti 0
EMail: priikone@iki.fi
-This Internet-Draft expires 15 November 2002
+This Internet-Draft expires XXX
projects / silc.git / blobdiff