Before describing how X.400 security services counter the threats
presented in Chapter \ref{x400-vulnerabilities}, three data structures 
must be discussed.
These data structures: the security label, the asymmetric token, and the 
public key certificate, are used to convey security-related information 
between communicating parties.  This chapter only defines the principal 
attributes comprising the structures; it provides no details regarding how 
these structures are used by X.400 security services.

\section{Security Label \label{x400-sl}}

A security label is a collection of attributes associated with an MHS
message or entity which permits its classification in terms of a security 
level.  The security label attributes include:

\begin{description}
 \item [a security policy identifier] which identifies the security policy
       with which the security label is associated,
 \item [a printable privacy mark] which identifies the level of privacy to be 
       afforded a message or report (e.g., 'In Confidence', 'In Strictest
       Confidence'),
 \item [a security classification] which classifies a message or report for
       security purposes (e.g., 'Unclassified', 'Confidential', 'Top 
       Secret'), 
 \item [a set of security categories] which restricts the context of the
       privacy mark, the security classification, or both.  The categories
       are application-defined, and may include codewords or caveats to
       the privacy mark or security classification (e.g., 'Personal-',
       'Staff-', 'Commercial-').
\end{description}

Security labels may be transferred in MHS messages and reports, conveyed 
during the association establishment between two MHS entities (e.g., a UA 
may transfer security labels when connecting to its MTA), or registered with 
MHS entities (e.g., an MTA may maintain a registry of security labels for its 
users).

\section{Asymmetric Token \label{x400-at}}

The asymmetric token is a signed data structure used to convey 
security-related information from an originator to a recipient.  The 
attributes comprising the token include:

\begin {itemize}
 \item the token signature
 \item the object identifier of the algorithm used to compute the signature,
 \item any input parameters (other than the token being signed) used to 
 	compute the signature,
 \item the name of the recipient,
 \item the date and time the token was generated,
 \item a non-repeating number,
 \item a collection of fields that is signed (signed-data):
 \begin{itemize}
   \item a content integrity check,
   \item a message security label,
   \item a request for proof of delivery,
   \item a message sequence number,
 \end{itemize}
\item a collection of fields that is encrypted (encrypted-data):
 \begin{itemize}
   \item a symmetric key used to encrypt the content,
   \item a symmetric key used to compute a content integrity check,
   \item a content integrity check,
   \item a message security label,
   \item a message sequence number.
 \end{itemize}
\end{itemize}

The asymmetric token provides three forms of cryptographic protection.
First, it ensures that only the recipient can view the plaintext
information in the encrypted-data.  This is because the token originator
encrypts the encrypted-data using the recipient's public asymmetric key.
Thus, only the recipient's private asymmetric key can be used to decrypt 
the information.  Second, it ensures that the token has not been modified.
This is because the originator signs the token.  The recipient can
validate the signature and confirm the token's integrity.  Third, it
authenticates the identity of the token originator.  This is because the
originator signs the token using its private asymmetric key.  If the
recipient validates the signature using the originator's public key
certificate, only the originator's corresponding private key could have
generated the signature.
\vspace{5 mm}

X.400 defines two purposes for asymmetric tokens.  They can be transferred 
as credentials when an MHS entity initiates a connection to a peer, and 
wants to provide strong authentication information.  For this purpose the
token is referenced as a {\em bind} token.  Tokens can also be transferred 
in MHS messages, such that a distinct token can be generated for each message 
recipient.  For this purpose the token is referenced as a {\em message}
token.

\section{Public Key Certificates \label{x400-pkc}}

In order for a public key scheme to be successful, users must be
guaranteed that the public key of another user truly belongs to that user.
The means by which a public key is bound to a user is the public key
certificate.  The public key certificate is a collection of information 
issued and signed by a CA (Certification Authority).  A certificate 
contains:

\begin{itemize}
 \item the owner's public asymmetric encryption key, 
 \item the DN (Distinguished Name) of the owner, 
 \item the DN of the certification authority, 
 \item the period during which the certificate is valid, 
 \item a version number,
 \item a serial number,
 \item the certificate signature.
\end{itemize} 

When a CA issues a certificate to a user, the CA provides a copy of its 
public key.  With this key the user can validate certificates 
issued to other users subscribing to the same authority.  To validate
certificates issued by different authorities, a {\em certification path} 
(i.e., a path of trusted certificates) must be constructed between the 
two users.  For example, if {\em User1} subscribes to {\em CA1}, 
{\em User2} subscribes to {\em CA2}, and both {\em CA1} and {\em CA2} 
have a trusted relationship with {\em CA3}, the certification
path {\em (C1, C3, C2)} can be constructed, allowing {\em User1} and
{\em User2} to obtain each other's public key.  This concept of CAs
generating certificates for other CAs is called {\em cross certification}.
Figure \ref{fig:x400-pkc} illustrates a hierarchical CA structure for cross 
certification.  In the hierarchical model, CAs only generate certificates 
for the entities (i.e., CAs or users) below them.
\vspace{5 mm}

An asymmetric key management scheme is presented in the directory system
authentication framework, described in Recommendation X.509 \cite{bib:x509}.  
The directory can be used to store public key certificates for MHS entities.  
These certificates can be accessed by other MHS entities to compute 
and/or validate the integrity and confidentiality of MHS messages.
\vspace{5 mm}

Within the MHS, public key certificates may be conveyed by several
methods.  When an MHS entity initiates a connection to a peer, it may 
transfer its public key certificate for the peer to use to validate its 
credentials.  Certificates can be registered with MHS 
entities, and transferred in MHS messages and reports.  MHS entities can 
also obtain public key certificates by some means outside the MHS, such 
as accessing the X.500 directory.

\begin{figure} \centering
 \input{x400_pkc}
 \caption{Hierarchical Model for Certification Authorities}
 \label{fig:x400-pkc}
\end{figure}
