appendixc.tex

早期freebsd实现

% appendix C

\appendix{C}{Differences between the ANSI and TTI drafts}

The differences between the \ansi/ draft standard for
financial institution key management,
and the \TTI/ draft's specification for trusted mail handling,
are considered.

The concept of a {\it key distribution center}
(\CKD/ in the \ansi/ draft, \KDC/ in the \TTI/ draft)
environment differs.
In the \ansi/ draft,
only one party talks to the {\it key distribution server} (\KDS/);
in the \TTI/ draft,
both parties talk to the \KDS/.
This leads to a number of differences in the two protocols.
The reason for this shift in the \TTI/ draft is somewhat subtle:
although both parties can talk to the \KDS/,
the {\it mail transfer system} (\MTS/)
environment is such that both {\it user agents} (\UA/s) are unable to
contact each other in real-time.
Hence, a detailed two-way protocol between them is prohibitively expensive.%
\nfootnote{In the words of Einar A.~Stefferud:
``Every interesting connection has at least two end-points~---~connections
with only one end-point are always uninteresting.''}

Before discussing the differences between the two drafts,
let us consider the differences in the two environments:
in the electronic mail environment,
the two end-to-end peers need not be simultaneously online.
Electronic mail relies on a communication service with potentially large
delays in transit between {\it message transfer agents} (\MTA/s).
A basic concept of ``mail'' is that an originator must release the enveloped
message to a ``transfer agent'' before delivery can be attempted to a
recipient.
In contrast,
in the electronic funds environment,
the two peers make use of a virtual-circuit service.
This means that they can synchronize much easier
and inter-operate in a more direct fashion.

Service protocols are based on the notion of requests and responses.
A client issues a request to a server,
the server processes the request and returns a response.
Depending on the complexity of the protocol,
the client may now respond to the server's message,
or might issue a new request,
or might terminate the connection.

As delays in the network increase,
along with the possibility of loss or corruption or re-ordering of messages,
it becomes more difficult to implement a service protocol.
In the case of a high-level protocol making use of a virtual-circuit service,
most problems can be ignored,
as the virtual-circuit service masks out problems in the network
by using sequences, positive (and/or negative) acknowledgments, windows,
and so on.

Sadly, electronic mail cannot utilize a virtual-circuit throughout the \MTS/
(although individual \MTA/-wise connections are (in theory) virtual-circuit
based).
This means that implementing a real-time or interactive
service protocol between two endpoints (a.k.a.~\UA/s)
in the \MTS/ is very difficult.
As a result,
the complexity of an end-to-end protocol in the \MTS/
(in terms of requests and responses)
is severely constrained.
For all practical purposes,
an \MTA/ can assume datagram service and nothing else:
messages might be re-ordered;
messages might not reach their destination;
messages might be corrupted (though this is unlikely);
in cases of failure, a notice might be generated, or might not.

In terms of the environment in which {\it cryptographic service messages}
(\CSM/s) must flow,
the high degree of delay and uncertainty make the implementation of a complex
end-to-end protocol between \UA/s prohibitively expensive.
Hence, a \KDC/ is needed,
to which each \UA/ can connect using a virtual-circuit service,
at posting and delivery time.
The \TTI/ draft terms such a user agent a {\it trusted mail agent} (\TMA/).
Since both \TMA/s can connect to the \KDS/ at different times using different
media,
the \KDS/ maintains state information about the key relationships between
different \TMA/s and manages those relationships appropriately.
Since connections to the \KDS/ can be expensive in terms of resources,
each \TMA/ caches information received from the \KDS/ appropriately.

That's the gist of the argument as to why the \TTI/ draft differs from the
\ansi/ draft.
It might be possible to include \CSM/s in the messages which \UA/s exchange,
but management of these \CSM/s can not be done reliably or in a straightforward
fashion owing to the datagram nature of the service offered by the \MTS/.
Finally, it should be noted that in the \TTI/ draft,
the \KDS/ never initiates a connection with a \TMA/,
rather it is the \TMA/s which connect to the \KDS/.

In the following,
the differences between the two drafts are highlighted.
Minor differences between the two are not discussed.

In the \ansi/ draft,
$\S 4.2$ (p.~22) discusses the requirements for the automated key
management architecture.
The \TTI/ draft has somewhat more ``depth'',
since the \ansi/ draft does not make use of a {\it master key} (MK)
to fully automate the distribution of {\it key-encrypting keys} (KK).

The \ansi/ draft states that once a KK-relationship is discontinued by either
of that pair,
the relation is not to be re-used for any subsequent activity.
This can't be guaranteed in the prototype implementation.
If one of the \TMA/s wishes to discontinue a key,
not only does it have to inform the \KDS/,
but the other \TMA/ as well.
Since the \TTI/ draft does not permit \CSM/s between \TMA/-peers,
the latter action doesn't seem possible.
However, there is a solution.
Whenever a message is deciphered,
the \TMA/ checks the effective date of the key used to
encrypt a message it has received,
and if the key is newer than the one it currently uses,
it considers the older key to be discontinued.

Furthermore,
although the environment in the \TTI/ draft is that of a key distribution
center,
the notion of an {\it ultimate recipient} is not present,
since all clients connect to the \KDS/ at one time or another.
In addition,
the differences between the environs envisioned by the two drafts
become even more pronounced when one considers that the \KDS/ distributes
key-encrypting keys to \TMA/s,
although the \ansi/ draft specifically prohibits this.

Finally,
there is another important technical difference between the two
drafts:
every request to the \KDS/ by the \TMA/
results in a specifically defined response from the \KDS/ to the \TMA/.
Furthermore,
if the \KDS/ responds in a positive manner,
then the \TMA/ acknowledges this.
This three-way interaction is used to ensure consistency between the states
of the \KDS/ and the \TMA/.
The \ansi/ draft does not require such behavior,
and might profit from some finite-state analysis to ascertain unsafe
(in terms of correctness) states which are reachable.