Message
DiME, the open and trust-based data format building secure Application-based Public-Key Infrastructures (APKIs) in a breeze.
Message items are used to protect the confidentiality and integrity of data that may sent between entities with an Application-based Public-Key Infrastructure.
Apart from the required integrity protection and optional end-to-end encryption, DiME message items are very similar to Data items.
The follwoing is an example of a DiME data item:
The header of a DiME message item is always 'MSG' as seen in the above example following the colon (':') after the envelope header ('Di').
Components
A DiME message item consists of several components. Each component is separated by a dot (‘.’), which is referred to as a component separator.
The following components make up a data item:
Header - always 'MSG'
Claims - required
Payload - required
Signature - required
Claims
Claims are information or data related to the data item, or its payload. These may include an issued at date, an expiration date and the MIME type of the payload data.
Example of a decoded claims component:
Claims used for message items are the same as for data items. For additional information about claims used for a Message refer to Claims and the claims section under Data.
The public key stored in the "pub" claim, is always assumed to have the capability Exchange. For refering to other keys, for example with capability Encrypt, it is recommended to use the key ID claim ("kid"), which would contain the unique id to the key that should be used to decrypt the payload. Key ID may also be used to refer to an external public-key pair for a key exchange.
Payload
As with data items, the third component of message items is the payload data. Unlike data items, message items allows for this data to be end-to-end encrypted.
End-to-end encryption is achieved by using two Key items with the capability 'exchange'. One key is received from the remote entity, and must only be the public version, where as the second key is generated by the sending entity.
The distribution of the keys may happen in many different ways. The public version may be included in the same DiME envelope as the message item, or the Key ID ('kid') claim may be used to refer to a previously distributed key. A third option is to use the Public key ('pub') field of the Message item.
Signature
The final component in a message item is always the signature. Any message item that is missing a signature component must always be discarded. The message item must also be discarded if the signature verification fails.
For additional details around the format of signature see Signature encoding.
Last updated