.ds RF FORMFEED[Page %]
.ds CF
.ds LH Internet Draft
-.ds RH XXX
+.ds RH 15 May 2002
.ds CH
.na
.hy 0
.nf
Network Working Group P. Riikonen
Internet-Draft
-draft-riikonen-silc-spec-05.txt XXX
-Expires: XXX
+draft-riikonen-silc-spec-05.txt 15 May 2002
+Expires: 15 November 2002
.in 3
3.2.2 Server ID ........................................... 11
3.2.3 SILC Server Ports ................................... 12
3.3 Router .................................................... 12
- 3.3.1 Router's Local ID List .............................. 12
+ 3.3.1 Router's Local ID List .............................. 13
3.3.2 Router's Global ID List ............................. 13
3.3.3 Router's Server ID .................................. 14
3.4 Channels .................................................. 14
- 3.4.1 Channel ID .......................................... 16
+ 3.4.1 Channel ID .......................................... 15
3.5 Operators ................................................. 16
3.6 SILC Commands ............................................. 16
3.7 SILC Packets .............................................. 17
3.8 Packet Encryption ......................................... 17
- 3.8.1 Determination of the Source and the Destination ..... 17
+ 3.8.1 Determination of the Source and the Destination ..... 18
3.8.2 Client To Client .................................... 18
- 3.8.3 Client To Channel ................................... 19
+ 3.8.3 Client To Channel ................................... 20
3.8.4 Server To Server .................................... 20
3.9 Key Exchange And Authentication ........................... 20
- 3.9.1 Authentication Payload .............................. 20
- 3.10 Algorithms ............................................... 22
- 3.10.1 Ciphers ............................................ 22
- 3.10.2 Public Key Algorithms .............................. 23
+ 3.9.1 Authentication Payload .............................. 21
+ 3.10 Algorithms ............................................... 23
+ 3.10.1 Ciphers ............................................ 23
+ 3.10.2 Public Key Algorithms .............................. 24
3.10.3 Hash Functions ..................................... 24
- 3.10.4 MAC Algorithms ..................................... 24
+ 3.10.4 MAC Algorithms ..................................... 25
3.10.5 Compression Algorithms ............................. 25
- 3.11 SILC Public Key .......................................... 25
- 3.12 SILC Version Detection ................................... 27
+ 3.11 SILC Public Key .......................................... 26
+ 3.12 SILC Version Detection ................................... 28
3.13 Backup Routers ........................................... 28
- 3.13.1 Switching to Backup Router ......................... 29
- 3.13.2 Resuming Primary Router ............................ 30
- 3.13.3 Discussion on Backup Router Scheme ................. 32
-4 SILC Procedures ............................................... 33
- 4.1 Creating Client Connection ................................ 33
- 4.2 Creating Server Connection ................................ 34
- 4.2.1 Announcing Clients, Channels and Servers ............ 35
- 4.3 Joining to a Channel ...................................... 36
- 4.4 Channel Key Generation .................................... 37
- 4.5 Private Message Sending and Reception ..................... 38
- 4.6 Private Message Key Generation ............................ 38
- 4.7 Channel Message Sending and Reception ..................... 39
- 4.8 Session Key Regeneration .................................. 39
- 4.9 Command Sending and Reception ............................. 40
- 4.10 Closing Connection ....................................... 41
-5 Security Considerations ....................................... 41
-6 References .................................................... 42
-7 Author's Address .............................................. 44
+ 3.13.1 Switching to Backup Router ......................... 30
+ 3.13.2 Resuming Primary Router ............................ 31
+ 3.13.3 Discussion on Backup Router Scheme ................. 33
+4 SILC Procedures ............................................... 34
+ 4.1 Creating Client Connection ................................ 34
+ 4.2 Creating Server Connection ................................ 35
+ 4.2.1 Announcing Clients, Channels and Servers ............ 36
+ 4.3 Joining to a Channel ...................................... 37
+ 4.4 Channel Key Generation .................................... 38
+ 4.5 Private Message Sending and Reception ..................... 39
+ 4.6 Private Message Key Generation ............................ 39
+ 4.7 Channel Message Sending and Reception ..................... 40
+ 4.8 Session Key Regeneration .................................. 40
+ 4.9 Command Sending and Reception ............................. 41
+ 4.10 Closing Connection ....................................... 42
+ 4.11 Detaching and Resuming a Session ......................... 42
+5 Security Considerations ....................................... 44
+6 References .................................................... 45
+7 Author's Address .............................................. 47
This document describes a Secure Internet Live Conferencing (SILC)
protocol which provides secure conferencing services over insecure
network channel. SILC is IRC [IRC] like protocol, however, it is
-not equivalent to IRC and does not support IRC.
+not equivalent to IRC and does not support IRC. Some of the SILC's
+features are not found in IRC but in traditional Instant Message (IM)
+protocols. SILC combines features from both of these chat protocol
+styles, and SILC can be implemented as either IRC-like system or
+IM-like system.
Strong cryptographic methods are used to protect SILC packets inside
the SILC network. Three other Internet Drafts relates very closely
requires message and command sending. The SILC Packet Protocol is
described in [SILC2] and should be read to fully comprehend this
document and protocol. [SILC2] also describes the packet encryption
-and decryption in detail.
+and decryption in detail. The SILC Packet Protocol provides secured
+and authenticated packets, and the protocol is designed to be compact.
+This makes SILC also suitable in environment of low bandwidth
+requirements such as mobile networks. All packet payloads in SILC
+can be also compressed.
The security of SILC protocol, and for any security protocol for that
matter, is based on strong and secure key exchange protocol. The SILC
are in the center of the cell and servers are connected to the router.
-
-
-
-
-
The following diagram represents SILC network topology.
.in 8
represents message sending between cells.
+
+
+
.in 16
.nf
1 --- S1 S4 --- 5 S2 --- 1
must not routers use each other as their primary routes. The router
connections in the network must form a ring.
-
-
-
-
-
-
Example with three routers in the network:
to be used along with the nicknames to identify specific users when sending
messages. This feature of SILC makes IRC style nickname-wars obsolete as
no one owns their nickname; there can always be someone else with the same
-nickname. The maximum length of nickname is 128 characters.
+nickname. The maximum length of nickname is 128 bytes.
.ti 0
possible to have 2^8 same nicknames from the same
server IP address.
-o MD5 hash - MD5 hash value of the nickname is truncated
- taking 88 bits from the start of the hash value. This
- hash value is used to search the user's Client ID from
- the ID lists.
+o MD5 hash - MD5 hash value of the lowercase nickname is
+ truncated taking 88 bits from the start of the hash value.
+ This hash value is used to search the user's Client ID
+ from the ID lists. Note that the nickname MUST be in
+ lowercase format.
.in 3
Collisions could occur when more than 2^8 clients using same nickname
messages addressed to that channel. The channel is created when first
client requests JOIN command to the channel, and the channel ceases to
exist when the last client has left it. When channel exists, any client
-can reference it using the name of the channel.
+can reference it using the name of the channel. If the channel has
+a founder mode set and last client leaves the channel the channel does
+not cease to exist. The founder mode can be used to make permanent
+channels in the network. The founder of the channel can regain the
+channel founder privileges on the channel later when he joins the
+channel.
Channel names are unique although the real uniqueness comes from 64 bit
Channel ID. However, channel names are still unique and no two global
-channels with same name may exist. The Channel name is a string of
-maximum length of 256 characters. Channel names MUST NOT contain any
-spaces (` '), any non-printable ASCII characters, commas (`,') and
-wildcard characters.
+channels with same name may exist. The channel name is a string of
+maximum length of 256 bytes. Channel names MUST NOT contain any
+whitespaces (` '), any non-printable ASCII characters, commas (`,')
+and wildcard characters.
Channels can have operators that can administrate the channel and
operate all of its modes. The following operators on channel exist on
Client usually sends the commands and server replies by sending a reply
packet to the command. Server MAY also send commands usually to serve
-the original client's request. However, server MUST NOT send commands
-to client and there are some commands that server must not send.
+the original client's request. Usually server cannot send commands to
+clients, however there MAY be commands that allow the server to send
+commands to client. By default servers MAY send commands only to other
+servers and routers.
Note that the command reply is usually sent only after client has sent
the command request but server is allowed to send command reply packet
-to client even if client has not requested the command. Client MAY,
+to client even if client has not requested the command. Client MAY
choose to ignore the command reply.
It is expected that some of the commands may be miss-used by clients
Every packet sent from client to server, with exception of packets for
channels, are encrypted with this session key.
-Channels has their own key that are shared by every client on the channel.
+Channels has a channel key that are shared by every client on the channel.
However, the channel keys are cell specific thus one cell does not know
the channel key of the other cell, even if that key is for same channel.
Channel key is also known by the routers and all servers that has clients
The header in the packet MUST NOT change during the routing of the
packet. The original sender, for example client, assembles the packet
and the packet header and server or router between the sender and the
-receiver MUST NOT change the packet header.
+receiver MUST NOT change the packet header. Note however, that some
+packets such as commands may resent by a server to serve the client's
+original command. In this case the command packet send by the server
+includes the server's IDs.
Note that the packet and the packet header may be encrypted with
different keys. For example, packets to channels are encrypted with
message delivery key with each other and that is used in
the message encryption.
-o Client 1. sends encrypted packet to its server. The packet is
- encrypted with the private message delivery key shared between
- clients.
+o Client 1. sends encrypted packet to its server. The packet header
+ is encrypted with the session key shared between the client and
+ server, and the private message is encrypted with the private
+ message delivery key shared between clients.
o Server determines the destination of the packet and sends the
packet to the router.
client connecting to the server. However, usually clients are accepted
to connect to server without explicit authentication. Servers are
required use authentication protocol when connecting. The authentication
-may be based on passphrase (pre-shared-secret) or public key. The
-connection authentication protocol is described in detail in [SILC3].
+may be based on passphrase (pre-shared-secret) or public key. All
+passphrases sent in SILC protocol MUST be UTF-8 [RFC2279] encoded.
+The connection authentication protocol is described in detail in [SILC3].
.ti 0
3.9.1 Authentication Payload
Authentication payload is used separately from the SKE and the Connection
-Authentication protocol. It is used during the session to authenticate
+Authentication protocol. It can be used during the session to authenticate
with the remote. For example, the client can authenticate itself to the
server to become server operator. In this case, Authentication Payload is
used.
.in 6
o Payload Length (2 bytes) - Length of the entire payload.
-o Authentication Method (2) - The method of the authentication.
- The authentication methods are defined in [SILC2] in the
- Connection Auth Request Payload. The NONE authentication
- method SHOULD NOT be used.
+o Authentication Method (2 bytes) - The method of the
+ authentication. The authentication methods are defined
+ in [SILC2] in the Connection Auth Request Payload. The NONE
+ authentication method SHOULD NOT be used.
o Public Data Length (2 bytes) - Indicates the length of
the Public Data field.
the signature process, described subsequently.
o Authentication Data Length (2 bytes) - Indicates the
- length of the Authentication Data field.
+ length of the Authentication Data field. If zero (0)
+ value is found in this field the payload MUST be
+ discarded.
o Authentication Data (variable length) - Authentication
method dependent authentication data.
If the authentication method is password based, the Authentication
-Data field includes the plaintext password. It is safe to send
-plaintext password since the entire payload is encrypted. In this
-case the Public Data Length is set to zero (0), but MAY also include
+Data field includes the plaintext UTF-8 encoded password. It is safe
+to send plaintext password since the entire payload is encrypted. In
+this case the Public Data Length is set to zero (0), but MAY also include
random data for padding purposes. It is also RECOMMENDED that maximum
amount of padding is applied to SILC packet when using password based
authentication. This way it is not possible to approximate the length
Authentication Data = sign(HASH);
The hash() and the sign() are the hash function and the public key
-cryptography function selected in the SKE protocol. The public key
+cryptography function selected in the SKE protocol, unless otherwise
+stated in the context where this payload is used. The public key
is SILC style public key unless certificates are used. The ID is the
entity's ID (Client or Server ID) which is authenticating itself. The
-ID is raw ID data. The random bytes are non-zero random bytes of
-length between 128 and 4096 bytes, and will be included into the
-Public Data field as is.
+ID encoding is described in [SILC2]. The random bytes are non-zero
+random bytes of length between 128 and 4096 bytes, and will be included
+into the Public Data field as is.
The receiver will compute the signature using the random data received
in the payload, the ID associated to the connection and the public key
(or certificate) received in the SKE protocol. After computing the
-receiver MUST verify the signature. In this case also, the entire
-payload is encrypted.
+receiver MUST verify the signature. In case of public key authentication
+this payload is also encrypted.
.ti 0
Additional public key algorithms MAY be defined to be used in SILC.
+When signatures are computed in SILC the computing of the signature is
+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].
+
.ti 0
3.10.3 Hash Functions
.in 3
All fields in the public key are in MSB (most significant byte first)
-order.
+order. All strings in the public key are UTF-8 encoded.
.ti 0
.in 3
Protocol version MAY provide both major and minor version. Currently
-implementations MUST set the protocol version and accept the protocol
-version as SILC-1.0-<software version>. If new protocol version causes
-in compatibilities with older version the the <minor> versio number MUST
-be incremented. The <major> is incremented if new protocol version is
-fully incompatible.
+implementations MUST set the protocol version and accept at least the
+protocol version as SILC-1.1-<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.
-Software version MAY provide major, minor and build version. The
-software version MAY be freely set and accepted.
+Software version MAY provide major, minor and build (vendor) version.
+The software version MAY be freely set and accepted. The version string
+MUST consist of printable US-ASCII characters.
Thus, the version strings could be, for example:
.in 6
-SILC-1.0-1.2
SILC-1.1-2.0.2
-SILC-1.0-1.0.VendorXYZ
+SILC-1.0-1.2
+SILC-1.1-1.0.VendorXYZ
+SILC-1.1-2.4.5 Vendor Limited
.in 3
Also, if any other router in the network is using the cell's primary
router as its own primary router, it must also have passive connection
to the cell's backup router. It too is prepared to switch to use the
-backup router as its new primary router as soon as the orignal primary
+backup router as its new primary router as soon as the original primary
router becomes unresponsive.
All of the parties of this protocol knows which one is the backup router
backup router. The backup router usually needs to do local modifications
to its database in order to update all the information needed to maintain
working routes. The backup router must understand that clients that
-were orignated from the primary router are now originated from some of
+were originated from the primary router are now originated from some of
the existing server connections and must update them accordingly. It
must also remove those clients that were owned by the primary router
since those connections were lost when the primary router became
3.13.2 Resuming Primary Router
Usually the primary router is unresponsive only a short period of time
-and it is intended that the original router of the cell will reassume
+and it is intended that the original router of the cell will resume
its position as primary router when it comes back online. The backup
router that is now acting as primary router of the cell must constantly
try to connect to the original primary router of the cell. It is
3.13.3 Discussion on Backup Router Scheme
It is clear that this backup router support is not able to handle all
-possible situations arrising in unreliable network environment. This
+possible situations arising in unreliable network environment. This
scheme for example does not handle situation when the router actually
does not go offline but the network link goes down temporarily. It would
require some intelligence to figure out when it is best time to switch
client to its router (or if the server is router, to all routers in
the SILC network). More information about this in [SILC2].
+Router server MUST also check whether some client in the local cell
+is watching for the nickname this new client has, and send the
+SILC_NOTIFY_TYPE_WATCH to the watcher.
+
.ti 0
4.2 Creating Server Connection
it should have cached the Client ID from the SILC Packet Header.
If server receives a private message packet which includes invalid
-destionation Client ID the server MUST send SILC_COMMAND_IDENTIFY
-command reply packet destined to the client with error status.
+destination Client ID the server MUST send SILC_NOTIFY_TYPE_ERROR
+notify to the client with error status indicating that such Client ID
+does not exist.
See [SILC2] for description of private message encryption and decryption
process.
in [SILC3], however, the HMAC key material MUST be discarded.
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.
+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.
+
.ti 0
4.7 Channel Message Sending and Reception
distribute the message to all clients on the channel by sending the
channel message destined explicitly to a client on the channel.
-See the [SILC2] for description of channel messege routing for router
-servers.
+If server receives a channel message packet which includes invalid
+destination Channel ID the server MUST send SILC_NOTIFY_TYPE_ERROR
+notify to the sender with error status indicating that such Channel ID
+does not exist.
-See [SILC2] for description of channel message encryption and decryption
-process.
+See the [SILC2] for description of channel message routing for router
+servers, and channel message encryption and decryption process.
.ti 0
Client usually sends the commands in the SILC network. In this case
the client simply sends the command packet to server and the server
-processes it and replies with command reply packet.
+processes it and replies with command reply packet. See the [SILC3]
+for detailed description of all commands.
However, if the server is not able to process the command, it is sent
to the server's router. This is case for example with commands such
local clients that are joined on the same channels with the remote
server's or router's clients.
+Router server MUST also check whether some client in the local cell
+is watching for the nickname this client has, and send the
+SILC_NOTIFY_TYPE_WATCH to the watcher, unless the client which left
+the network has the SILC_UMODE_REJECT_WATCHING user mode set.
+
+
+.ti 0
+4.11 Detaching and Resuming a Session
+
+SILC protocol provides a possibility for a client to detach itself from
+the network without actually signing off from the network. The client
+connection to the server is closed but the client remains as valid client
+in the network. The client may then later resume its session back from
+any server in the network.
+
+When client wishes to detach from the network it MUST send the
+SILC_COMMAND_DETACH command to its server. The server then MUST set
+SILC_UMODE_DETACHED mode to the client and send SILC_NOTIFY_UMODE_CHANGE
+notify to its primary router, which will then MUST broadcast it further
+to other routers in the network. This user mode indicates that the
+client is detached from the network. Implementations MUST NOT use
+the SILC_UMODE_DETACHED flag to determine whether a packet can be sent
+to the client. All packets MUST still be sent to the client even if
+client is detached from the network. Only the server that originally
+had the active client connection is able to make the decision after it
+notices that the network connection is not active. In this case the
+default case is to discard the packet.
+
+The SILC_UMODE_DETACHED flag cannot be set by client itself directly
+with SILC_COMMAND_UMODE command, but only implicitly by sending the
+SILC_COMMAND_DETACH command. The flag also cannot be unset by the
+client, server or router with SILC_COMMAND_UMODE command, but only
+implicitly by sending and receiving the SILC_PACKET_RESUME_CLIENT
+packet.
+
+When the client wishes to resume its session in the SILC Network it
+connects to a server in the network, which MAY also be a different
+from the original server, and performs normal procedures regarding
+creating a connection as described in section 4.1. After the SKE
+and the Connection Authentication protocols has been successfully
+completed the client MUST NOT send SILC_PACKET_NEW_CLIENT packet, but
+MUST send SILC_PACKET_RESUME_CLIENT packet. This packet is used to
+perform the resuming procedure. The packet MUST include the detached
+client's Client ID, which the client must know. It also includes
+Authentication Payload which includes signature made with the client's
+private key. The signature is computed as defined in the section
+3.9.1. Thus, the authentication method MUST be based in public key
+authentication.
+
+When server receives the SILC_PACKET_RESUME_CLIENT packet it MUST
+do the following: Server checks that the Client ID is valid client
+and that it has the SILC_UMODE_DETACHED mode set. Then it verifies
+the Authentication Payload with the detached client's public key.
+If it does not have the public key it retrieves it by sending
+SILC_COMMAND_GETKEY command to the server that has the public key from
+the original client connection. The server MUST NOT use the public
+key received in the SKE protocol for this connection. If the
+signature is valid the server unsets the SILC_UMODE_DETACHED flag,
+and sends the SILC_PACKET_RESUME_CLIENT packet to its primary router.
+The routers MUST broadcast the packet and unset the SILC_UMODE_DETACHED
+flag when the packet is received. If the server is router server it
+also MUST send the SILC_PACKET_RESUME_CLIENT packet to the original
+server whom owned the detached client.
+
+The servers and routers that receives the SILC_PACKET_RESUME_CLIENT
+packet MUST know whether the packet already has been received for
+the client. It is protocol error to attempt to resume the client
+session from more than one server. The implementations could set
+internal flag that indicates that the client is resumed. If router
+receive SILC_PACKET_RESUME_CLIENT packet for client that is already
+resumed the client MUST be killed from the network. This would
+indicate that the client is attempting to resume the session more
+than once which is protocol error. In this case the router sends
+SILC_NOTIFY_TYPE_KILLED to the client. All routers that detect
+the same situation MUST also send the notify for the client.
+
+The servers and routers that receive the SILC_PACKET_RESUME_CLIENT
+must also understand that the client may not be found behind the
+same server that it originally came from. They must update their
+caches according this. The server that now owns the client session
+MUST check whether the Client ID of the resumed client is based
+on the server's Server ID. If it is not it creates a new Client
+ID and send SILC_NOTIFY_TYPE_NICK_CHANGE to the network. It MUST
+also send the channel keys of all channels that the client is
+joined to the client since it does not have them. Whether the
+Client ID was changed or not the server MUST send SILC_PACKET_NEW_ID
+packet to the client. Only after this the client is resumed back
+to the network and may start sending packets and messages.
+
+It is also possible that the server does not know about the channels
+that the client has joined. In this case it join the client internally
+to the channels, generate new channel keys and distribute the keys
+to the channels as described in section 4.4.
+
+It is implementation issue for how long servers keep detached client
+sessions. It is RECOMMENDED that the detached sessions would be
+persistent as long as the server is running.
+
.ti 0
5 Security Considerations
are running the service. It is recommended that some form of registration
is required by the server and router administrator prior acceptance to
the SILC Network. Even though, the SILC protocol is secure in a network
-of mutual distrust between clients, servers, routers and adminstrators
+of mutual distrust between clients, servers, routers and administrators
of the servers, the client should be able to trust the servers they are
-using if they whish to do so.
+using if they wish to do so.
It however must be noted that if the client requires absolute security
by not trusting any of the servers or routers in the SILC Network, it can
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 use many times session keys or other keys generated by the
-servers to secure the messages. This is intentional design feature to
-allow ease of use for end user. This way the network is still usable,
-and remains encrypted even if the external means of distributing the
-keys is not working. The implementation, however, may like to not
-follow this design feature, and always negotiate the keys outside SILC
-network. This is acceptable solution and many times recommended. The
-implementation still must be able to work with the server generated keys.
+not full proof system; the SILC servers and routers could very well be
+compromised. However, to provide acceptable level of security and
+usability for end user the protocol use many times session keys or other
+keys generated by the servers to secure the messages. This is
+intentional design feature to allow ease of use for end user. This way
+the network is still usable, and remains encrypted even if the external
+means of distributing the keys is not working. The implementation,
+however, may like to not follow this design feature, and always negotiate
+the keys outside SILC network. This is acceptable solution and many times
+recommended. The implementation still must be able to work with the
+server generated keys.
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
+negotiated 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.
6 References
[SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft,
- April 2001.
+ May 2002.
[SILC3] Riikonen, P., "SILC Key Exchange and Authentication
- Protocols", Internet Draft, April 2001.
+ Protocols", Internet Draft, May 2002.
-[SILC4] Riikonen, P., "SILC Commands", Internet Draft, April 2001.
+[SILC4] Riikonen, P., "SILC Commands", Internet Draft, May 2002.
[IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
RFC 1459, May 1993.
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
+[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
-
-
+[PKCS7] Kalinski, B., "PKCS #7: Cryptographic Message Syntax,
+ Version 1.5", RFC 2315, March 1998.
.ti 0
.nf
Pekka Riikonen
-Snellmanninkatu 34 A 15
+Snellmaninkatu 34 A 15
70100 Kuopio
Finland
EMail: priikone@iki.fi
-This Internet-Draft expires XXX
+This Internet-Draft expires 15 November 2002
projects / silc.git / blobdiff