What further modules are required?

Plasma provides three security services for data transmissions in its current implementation; they are non-repudiation , confidentiality and integrity . The object-oriented design of the security platform allows the easy integration of further security services such as the protection from replay attacks or the digital signature creation .

For Plasma to be able to perform media specific operations on the application document data it is necessary that the security platform can call upon different and media specific protocols for the actual operation; this is realized by the concept of generic security services . A generic service non-repudiation not only provides one fixed protocol for realizing a non-repudiable component but rather has access to a number of different protocols which then perform the actual operation.

The security platform must be capable of activating the particular security services for each media type or structural element and their corresponding cryptographic protocol -- these can and should be media specific protocols.

The simplest and most obvious approach for this is to implement the corresponding parameters as self-sufficient modules of the platform. This results in the existence of the modules medium , generic security services and cryptographic protocols .

This architecture necessitates another module which creates the relations between these parameters; this relation must express which cryptographic protocol is to be used for a specific medium, structural element or document type with regard to an activated security service. This relation is designated within Plasma as the security policy since this relation actually describes the policy or mode of operation how different media are to be protected cryptographically during transmission -- it must in some form be capable of influencing the relations between the other three modules medium , generic security services and cryptographic protocols .

The security policy in Plasma is stored for each user as an ASCII file in the home directory of each user (FSP: formal security policy ), thus allowing each user to configure this policy to meet his needs prior to the secured communication itself. The actual use of these security policies in an ongoing communications session, their enforcement and application will be explained later.

The rough outline of the security platform is therefore predetermined to appear similar to Figure at the left side. It is obvious that further modules are required for the implementation of ``secure telecommunications'' when considering the entirety of a security platform; such objects as the Session object depicted in Figure which implements a secure connection between two communications partners within Plasma -- however, a detailed description of the object oriented design of Plasma was already given in [7] and shall not be repeated.