Single destination, non-session messages

These messages are for things that a key is stating about the world that are 'public' information. Examples of such messages include:

• Assertions that the key exists.
• Assertions that the key may be found at a particular address in a different protocol.
• Assertions that a new key is replacing the current key.
• Assertions that another key is authorized to handle messages for the key.
• Assertions that a key is willing to handle messages for another key.

There may be many other kinds of assertions message. The above messages are just given as examples of what kinds of things an assertion message is for.

As an assertion represents a 'public' statement, assertion messages are never encrypted. If you want to privately communicate a set of assertions to another party, you should encapsulate them in an encrypted session, or in a UnicastMessage for the purpose.

All assertions messages have a 'start' time and an 'expiration' time. These define an assertion message's lifetime. An assertion message is not valid, and should not be propogated before the 'start' time is reached. After the 'expiration' time has been reached, the assertion should no longer be considered valued or useful, and should be tossed out of caches, and not propogated.

While those rules apply to all assertion messages, some assertion messages have additional rules that apply. For example, the key existence assertion includes a 'drop dead' time after which the key should be considered comprimised. The expiration time is considered to be the time at which the key is no longer valid for new signatures.

The message number part of an assertion messages refers to the exact format of the assertion being made. This also usually restricts the assertion to some very specific class. In the future, there be an assertion type in which the assertion is made in a well-defined formal language that allows a wide variety of different assertions to be clearly expressed. But, that doesn't exist yet.

This will be a simple list of fields in the message. There are no repeating sections in assertion messages. All fields (except the signature itself of course) are signed in the form they appear in the message.