[Rt-commit] rt branch, 4.4/secure-email-doc, repushed

[Brian Duggan]

The branch 4.4/secure-email-doc was deleted and repushed:
       was 56a39b84df5ab5c811abb54921fb38a8d8227314
       now 88032f84d418bc13b4314afb64df2b042931aa71

1: 56a39b84d ! 1: 88032f84d WIP Add high-level secure email documentation
    @@ -34,6 +34,8 @@
     +
     +=head1 Background
     +
    ++=head2 What encrypted mail does
    ++
     +TLS encrypts the IMAP, POP, and SMTP connections from users' MUAs to
     +mail servers. It also encrypts the SMTP connections between mail
     +servers. This prevents entities like ISPs from eavesdropping on email
    @@ -54,7 +56,27 @@
     +them on display. Or RT can decrypt the messages on receipt and store
     +the decrypted content.
     +
    -+=head2 GnuPG background
    ++=head2 How encrypted mail works
    ++
    ++GnuPG and S/MIME both use public key cryptography. Each user must have
    ++a private key and a public key for their own identity. And each user
    ++must have a public key for every person they exchange encrypted mail
    ++with.
    ++
    ++Users encrypt messages to public keys. They decrypt mail encrypted to
    ++their own public key with their private key.
    ++
    ++Users sign messages with their private keys. They verify other users'
    ++signatures with those users' public keys.
    ++
    ++RT has its own set of keys, like any other encrypted mail user. RT
    ++must have at least one public and private key pair. It must also have
    ++the public keys for any email addresses that RT users want to exchange
    ++encrypted mail with.
    ++
    ++=head2 How GnuPG and S/MIME are different
    ++
    ++=head3 GnuPG background
     +
     +GnuPG does not depend on a trusted authority to distribute or verify
     +keys. Users can install any public key from any source and decide how
    @@ -63,7 +85,7 @@
     +
     +RT administrators must manage RT's GnuPG keyring manually.
     +
    -+=head2 S/MIME background
    ++=head3 S/MIME background
     +
     +S/MIME depends on a trusted authority to verify the authenticity of
     +other users' public keys.
    @@ -74,4 +96,35 @@
     +authorities, that sign the keys of users that want to communicate with
     +it.
     +
    ++=head1 Using encrypted mail with RT
    ++
    ++When two encrypted mail users communicate directly with each other,
    ++they must each have a collection of encryption keys. Each user must
    ++have a public key and a private key for their own identity. And they
    ++must have the other user's public key.
    ++
    ++When three encrypted mail users communicate directly with each other,
    ++they must each have public and private keys for themselves. And each
    ++of them must have the public keys for the other two users.
    ++
    ++Encrypted mail in RT operates differently. Instead of communicating
    ++directly with each other, RT acts as a mail intermediary. Users
    ++encrypt messages to RT's key. RT decrypts those messages. Then RT
    ++re-encrypts the messages to all mail recipients for that ticket. Users
    ++receive encrypted mail from RT, not the original sender.
    ++
    ++Users sign messages with their private key to send to RT. RT verifies
    ++those signatures. Then RT signs the message with its own key and sends
    ++it to all mail recipients for that ticket.
    ++
    ++When encrypted mail users communicate with each other through RT, each
    ++of them must have RT's public key. They do not need each others'
    ++public keys. Only RT must have every user's public key.
    ++
    ++=head2 An example
    ++
    ++=head3 The story of Alice and Bob.
    ++
    ++=head3 The story of Alice, Bob, Carol, and Faythe
    ++
     +=cut