clean up one last doc

doc/index.rst

@@ -52,15 +52,6 @@ and privacy enthusiasts.
 
 :doc:`faq`
 
-unsorted collection of docs and fragments
-+++++++++++++++++++++++++++++++++++++++++
-
-The following docs need refinement and incorporation into
-our sorted, maintained collection.
-
-:doc:`message-encryption`
-
-
 .. _`contact channels`:
 
 Channels

doc/next-steps.rst

@@ -63,3 +63,36 @@ see :doc:`backup`
 .. todo::
 
    We need guidance on how backups might be done safely.
+
+
+Guidance on masking Key IDs
+---------------------------
+
+If any recipients are in `Bcc:` (rather than `To:` or `Cc:`), and the
+key types used are all OpenPGP (`type=p`), then the agent SHOULD mask
+the recipient key ID in the generated PKESK packets that correspond to
+the Bcc'ed recipents.  It does not need to mask recipient key IDs of
+normal recipients.
+
+Masking of Key IDs is done by setting the key ID to all-zeros.  See
+the end of section 5.1 RFC 4880 for more details.  Users of GnuPG can
+use the `--hidden-recipient` argument to indicate a recipient who will
+be masked.
+
+This is so that the message encryption does not leak much additional
+metadata beyond what is already found in the headers of the message.
+It still leaks the number of additional recipients, but the additional
+work and usability issues involved with fixing that metadata leak
+suggest that it's better to leave that to a future level.
+
+
+Encrypted headers
+-----------------
+
+.. todo::
+
+   Document interaction with encrypted headers: if something like
+   memoryhole ever makes it possible to hide normal `To:` and `Cc:`
+   headers, then we need to rethink our approach to handling PKESK
+   leakage further.
+