Return to appendixA.tex CVS log

Up to [CSRG BSD Unix] / 43BSDReno / contrib / mh / papers / trusted

Annotation of 43BSDReno/contrib/mh/papers/trusted/appendixA.tex, revision 1.1

1.1     ! root        1: % appendix A
        !             2: 
        !             3: \appendix{A}{An MH Session}
        !             4: 
        !             5: \tagdiagram{A1-1}{Sending Encrypted Mail}{sendmail}
        !             6: In the following,
        !             7: the user \eg{Marshall\ T.\ Rose} logged onto host \eg{udel-dewey},
        !             8: wishes to send a message to a user known as
        !             9: the \eg{UCI\ Portal} (a system maintenance account).
        !            10: As shown in Figure~\sendmail, line~1,
        !            11: the user first establishes a mapping between the name \eg{UCI\ Portal} and
        !            12: the address {\tx uci@udel-dewey}.
        !            13: Once this mapping is performed,
        !            14: it remains in effect until the user indicates otherwise to the \TMA/.
        !            15: When the \pgm{tma} program is invoked,
        !            16: it consults the \TMA/ database to see if that user is known.
        !            17: If not,
        !            18: it contacts the \KDS/ to ask for the \KDS/ ID associated with the user.
        !            19: If the response is successful (in this case, the \KDS/ ID is \eg{3}),
        !            20: then the \TMA/ updates its database.
        !            21: The \pgm{tma} program indicates in its output the \KDS/ ID associated with
        !            22: the user,
        !            23: along with all known addresses (in this case, only one).
        !            24: So, once the name to address mapping has been described the user,
        !            25: the user agent, \MH/, deals only with the address,
        !            26: while the trusted mail agent deals with the name and \KDS/ ID aspects of the
        !            27: user.
        !            28: 
        !            29: Next, the \pgm{comp} program is invoked to compose a new draft on line~5.
        !            30: The user addresses the local user \eg{uci} in the To: field,
        !            31: and indicates that a plaintext copy should be kept in the folder \eg{+outbox}.
        !            32: After entering the subject and text of the draft,
        !            33: the user enters \whatnow/ level on line~13.
        !            34: At this point,
        !            35: the user directs \MH/ to send the draft in encrypted form.
        !            36: The resulting output is verbose (a default for \pgm{send} for this user)
        !            37: but instructive.
        !            38: Initially,
        !            39: all addresses in the draft are verified on lines~14 to~17.
        !            40: Two forms of verification occur:
        !            41: first, the \MTS/ is asked to verify the address as much as possible.
        !            42: For local addresses,
        !            43: the \MTS/ decides if the name has a maildrop associated with it.
        !            44: For remote addresses,
        !            45: the \MTS/ decides if the host is known to it.
        !            46: The second type of verification occurs with the \TMA/.
        !            47: For all addresses,
        !            48: the \TMA/ is asked if it can find a mapping from the address to a \KDS/ ID.
        !            49: 
        !            50: The reason \MH/ goes to all this trouble is a philosophical issue.
        !            51: Since the copy of the encrypted draft is different for each recipient,
        !            52: \pgm{post} tries to verify that all recipients can be successfully posted
        !            53: prior to actually posting the different ciphertext versions of the draft.
        !            54: This behavior is not optimal in terms of cycles,
        !            55: but is perhaps ``correct'' from a \UA/ perspective.
        !            56: 
        !            57: Finally, the draft is actually posted, and the folder carbon-copy is filed.
        !            58: 
        !            59: \tagdiagram{A1-2}{Receiving Encrypted Mail}{recvmail}
        !            60: Some time later, the UCI portal is informed that new mail has arrived.
        !            61: As shown in Figure~\recvmail,
        !            62: the \pgm{inc} program is run.
        !            63: The \eg{E} prior to the date of the message indicates that \pgm{inc} has
        !            64: detected the message to be encrypted.
        !            65: Since the user did not inhibit \pgm{inc} from deciphering the message,
        !            66: it proceeds to do so.
        !            67: 
        !            68: \tagdiagram{A1-3}{Message Prior to Decryption}{before}
        !            69: \tagdiagram{A1-4}{Message After Decryption}{after}
        !            70: Finally, it may be instructive to see what the encrypted message looked like
        !            71: when it was delivered to the portal's maildrop,
        !            72: and the final message after deciphering.
        !            73: Figures~\before\ and~\after\ show these respectively.
        !            74: In particular,
        !            75: note that the \eg{X-KDS-ID:} field has been introduced in Figure~\after\
        !            76: after successfully deciphering the message.
        !            77: The presence of this field authenticates the sender of the message.

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.