.ds RF FORMFEED[Page %]
.ds CF
.ds LH Internet Draft
-.ds RH 15 May 2002
+.ds RH 25 November 2002
.ds CH
.na
.hy 0
.nf
Network Working Group P. Riikonen
Internet-Draft
-draft-riikonen-flags-payloads-00.txt 15 May 2002
-Expires: 15 November 2002
+draft-riikonen-flags-payloads-01.txt 25 November 2002
+Expires: 25 April 2003
.in 3
.ce 2
SILC Message Flag Payloads
-<draft-riikonen-flags-payloads-00.txt>
+<draft-riikonen-flags-payloads-01.txt>
.ti 0
Status of this Memo
This memo describes the data payloads associated with the SILC Message
Flags, as defined in the SILC Packet Protocol Internet Draft [SILC2]. The
-purpose of the Message Flags is to augment the function of the Private
-Message Payload and Channel Message Payload by allowing the sender to
-tell the receiver what type of data the payload includes, and how the
-data should be processed. Some of the Message Flags may define additional
-payloads to be associated with the flag, and this memo describes these
-payloads.
+purpose of the Message Flags is to augment the function of the Message
+Payload used to send both private and channel messages, by allowing the
+sender to tell the receiver what type of data the payload includes, and
+how the data should be processed. Some of the Message Flags may define
+additional payloads to be associated with the flag, and this memo
+describes these payloads.
3.1 SILC_MESSAGE_FLAG_REQUEST ................................. 3
3.2 SILC_MESSAGE_FLAG_REPLY ................................... 3
3.3 SILC_MESSAGE_FLAG_SIGNED .................................. 4
- 3.4 SILC_MESSAGE_FLAG_DATA .................................... 4
-4 Security Considerations ....................................... 5
-5 References .................................................... 5
-6 Author's Address .............................................. 6
+ 3.4 SILC_MESSAGE_FLAG_DATA .................................... 6
+4 Security Considerations ....................................... 7
+5 References .................................................... 7
+6 Author's Address .............................................. 8
.ti 0
The Secure Internet Live Conferencing [SILC1] supports sending binary
messages between users in the network. To make the data sending, and
processing at the receiver's end as simple as possible the SILC defines
-Message Flags to the Private Message Payload and Channel Message Payload
-[SILC2], which can help the receiver to decide how the data is encoded,
-and how it should be interpreted. Some of the Message Flags may define
-additional payloads to be associated with the flag, but the [SILC2] does
-not define them. This memo defines the payloads for those Message Flags
-that was marked to include additional payloads in [SILC2].
-
-By defining the payloads for the Message Flags the SILC message payloads
+Message Flags to the Message Payload [SILC2] that is used to send private
+and channel messages, which can help the receiver to decide how the data
+is encoded, and how it should be interpreted. Some of the Message Flags
+may define additional payloads to be associated with the flag, but the
+[SILC2] does not define them. This memo defines the payloads for those
+Message Flags that was marked to include additional payloads in [SILC2].
+
+By defining the payloads for the Message Flags the Message Payload
can be augmented to support any kind of data, which can be easily
interpreted at the receiver end. For example, it would be possible to
send audio stream, video stream, image files and HTML pages as messages,
at all, or require encoding of the data before it can be sent over the
network.
-SILC Private Message Payload and Channel Message Payload can have flags
-that can augment the function of the payload. The flags can tell for
-example that the message is a request, or a reply to an earlier received
-request. They can tell that the message is some action that the sender
-is performing, or they can tell that the message is an auto reply, or
-that it is explicitly digitally signed by the sender.
+The Message Payload in SILC can have flags that can augment the function
+of the payload. The flags can tell for example that the message is a
+request, or a reply to an earlier received request. They can tell that
+the message is some action that the sender is performing, or they can tell
+that the message is an auto reply, or that it is explicitly digitally
+signed by the sender.
The problem of Message Flags is that the space for flags mask is only 16
bits, so there is a limited number of flags available. For this reason a
.ti 0
3.3 SILC_MESSAGE_FLAG_SIGNED
-Not defined yet.
+This flag is used to tell the recipient that the sent message is
+digitally signed by the sender, and that the recipient should verify
+the signature to verify the true authenticity of the received message.
+All message payloads in SILC provides message authentication code (MAC)
+which can be used to verify that the sender produced and sent the message.
+Even so, signing messages digitally can be used to verify the authenticity
+of the message when recipient trusts the sender.
+
+This flag defines a payload which is used to deliver the actual message,
+sender's public key and the digital signature. The payload for
+SILC_MESSAGE_FLAG_SIGNED is as follows:
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ Message Payload ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ Public Key Payload ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Signature Data Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Signature Data ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 1: SILC_MESSAGE_FLAG_SIGNED Payload
+
+
+.in 6
+o Message Payload (variable length) - This is the Message Payload
+ [SILC2] consisting of the encrypted message.
+
+o Public Key Payload (variable length) - This includes the
+ Public Key Payload [SILC2] which can be used to deliver the
+ sender's public key (or certificate). It also indicates the
+ type of the public key (or certificate) which the recipient
+ use to identify how the signature must be verified. This
+ payload must always be present but it is not required to
+ include the public key data. The Public Key Type field in
+ the Public Key Payload MUST be set to the correct type of
+ the key, even if the actual public key data is not included.
+
+o Signature Data Length (2 bytes) - Indicates the length of
+ the Signature Data field not including any other field.
+
+o Signature Data (variable length) - Includes the actual
+ signature data. The signature computation and encoding
+ is key type specific. See [SILC3] for all key types, and
+ their respective references of how to compute and encode
+ the signature.
+.in 3
+
+How the data is processed before it is signed is key type specific.
+The actual data that to be signed MUST be the plaintext message
+payload before encryption. The data to be signed is concatenation
+of Message Flags, Message Length, Message Data, Padding Length,
+Padding and Initial Vector fields, and the Public Key Payload, in
+that order. Any other fields is not included for signature data.
+Before signing, the data is always processed, usually hashed. The
+hash function to be used is defined in the key type specific
+definitions. See the key type specific references in [SILC3].
+
+If the public key of the sender is included in the payload the
+recipient SHOULD verify before accepting the public key. Recipient
+SHOULD verify the signature before accepting a public key. With
+certificates the certificate verification may be done before
+verifying the signature. If the signature verification fails the
+message should still be displayed. The end user should also be
+notified about the result of the signature verification.
+
+To make the packet size smaller implementations may not want to
+include the actual public key in all signed messages. Sending the
+public key in the first message is usually sufficient. Subsequent
+messages may include empty Public Key Payload with an indication of
+the public key type.
+
+Implementations that do not support this flag can still process the
+message payload in normal manner. These implementations merely ignore
+rest of the data after the message payload.
+
+This flag MAY be masked with any other Message Flag including those that
+define additional payloads. As long as the defined payload resides in
+the data area of the message payload this flag may be masked with the
+other flags.
+
.ti 0
"application/octet-stream". The receiver MAY also ignore and discard
messages that it does not support.
-The MIME header MUST be at the start of the data area of the Private
-Message Payload or Channel Message Payload. The MIME header received in
-the data area of the payload SHOULD have the MIME-Version field at first
-and then Content-Type field. The MIME-Version field is not required to be
-present in each body part of multipart entity. Additionally the header
-MAY also include any other MIME compliant headers. The character encoding
-for the MIME Header strings inside the message payload is US-ASCII, as
-defined in [RFC2045]. The actual MIME object may define additional
-character sets or encodings for the data it delivers.
+The MIME header MUST be at the start of the data area of the Message
+Payload. The MIME header received in the data area of the payload SHOULD
+have the MIME-Version field at first and then Content-Type field. The
+MIME-Version field is not required to be present in each body part of
+multipart entity. Additionally the header MAY also include any other
+MIME compliant headers. The character encoding for the MIME Header
+strings inside the message payload is US-ASCII, as defined in [RFC2045].
+The actual MIME object may define additional character sets or encodings
+for the data it delivers.
Hence, the MIME Header in the message payload may be as follows:
sender may also start sending fragmented MIME objects.
This flag SHOULD NOT be masked with some other Message Flag that defines
-payloads. Generally this sort of setting would be impossible for the
-receiver to interpret. However, flags that does not define any specific
-payloads MAY be masked with this flag as well. For example, this flag
-could be masked also with SILC_MESSAGE_FLAG_REQUEST flag.
+payloads for message data. Generally this sort of setting would be
+impossible for the receiver to interpret. However, flags that does not
+define any specific payloads MAY be masked with this flag as well. For
+example, this flag could be masked also with SILC_MESSAGE_FLAG_REQUEST flag.
+It also can be masked with SILC_MESSAGE_FLAG_SIGNED flag since it does not
+define data specific payload.
.ti 0
[SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft,
May 2002.
+[SILC3] Riikonen, P., "SILC Key Exchange and Authentication
+ Protocols", Internet Draft, May 2002.
+
[RFC2045] Freed, N., et al., "Multipurpose Internet Mail Extensions
(MIME) Part One: Format of Internet Message Bodies",
Standards Track, RFC 2045, November 1996.
EMail: priikone@iki.fi
-This Internet-Draft expires 15 November 2002
+This Internet-Draft expires 25 April 2003
projects / silc.git / blobdiff