comments on draft-miller-xmpp-e2e-06

Section 1
- This may be in the reqs draft, but seems worth stating here that some
end points for a given recipient may share keys, some may use different
keys, some may have no keys and some may not support encryption or
signature verification at all.

Section 3
- What should the sender do if some end points for a recipient indicate
lack of support for encryption?  Are error responses helpful independent
of confirmation that some end points support encryption?  Is the intent
for messages to only be sent to end points that advertise support?

- Why not include an end point's key in its info results and enable return
of the encrypted SMK (or even CEK) with the encrypted payload (to save a
round trip).  Given a single message could trigger a number of requests
for the SMK, the option to include the encrypted CEK in the payload may be
worthwhile.  Including the encrypted CEK would help with storage too.
 

- Why is the SID required to be unique for a {sender, recipient, SMK}
tuple?  This would allow for the same SID to be used to name every SMK
used with a recipient.  Suggest unique for each recipient (i.e., SMK's are
uniquely identified by recipient+SID for a given sender).

- Discuss how multiple recipients are handled

- s/optionallly/optionally

- It would be nice to have a summary of new state information the sender
and recipient are required to manage (like SMKs) and significant new
operations (like authorization of key requests where a given recipient may
use a number of different public keys)

- Should include an example of a reply to an encrypted message.
Should/must the same SMK be used in replies?

- Is there any reason pre-placed SMK values cannot be used instead of SMK
values retrieved automatically from the sender?

Section 4
- How is the public key used to verify signatures published to the
recipients?  If not included in the payload, should be available a la the
SMK.  This would be useful, at a minimum, when the signer uses a
certificate from a PKI the recipient trusts.

- s/Playload/payload

- Include some text indicating users MUST be able to determine if a
message was authenticated

- Should data be presented to the user when the timestamp is not
acceptable?  There are guidelines for invalid signatures, but not for
unacceptable timestamps.  Same comment on 3.3.5 too.

- May want to distinguish between successful authentication vs successful
verification

Section 5
- Should describe how the entity requesting a key gets the SID

- Should make it more clear that a new CEK is generated in order to
encrypt the SMK, then the CEK is encrypted under the public key.

Section 9
- The requirement for the sender to be online would seem like sufficient
grounds for including encrypted CEKs in the payload.

Section 11
- Offline storage may be another reason to include encrypted CEKs in a
payload.  Perhaps the solution should be to encrypt for each of a
recipient's known keys plus an SMK that could be used by end points using
a different, not-yet-known-to-the-sender key.

- Need to address authorization for SMK release.

- Include some guidance on SMK lifetime.