Draft: draft-ietf-mls-protocol

Commentary: As discussed in the mailing list , not having the signature contribute to the new epoch 's key schedule leads to a one - off effect where parties stay in sync ( with respect to keys ) for one more epoch , before inevitably go out of sync . This pull request addresses this issue by including the signature in the confirmed transcript hash rather than the interim transcript hash . See the mailing list for a security consideration of this change . Credit : This pull request was primarily authored by   ; I 'm just posting it here for administrative reasons .
Paragraph (version A):
Thus the "confirmed_transcript_hash" field in a GroupContext object
represents a transcript over the whole history of MLSPlaintext Commit
messages, up to the confirmation tag field in the current
MLSPlaintext message.  The confirmation tag and signature fields are
then included in the transcript for the next epoch.  The interim
transcript hash is passed to new members in the GroupInfo struct, and
enables existing members to incorporate a Commit message into the
transcript without having to store the whole
MLSPlaintextCommitAuthData structure.
Paragraph (version B):
Thus the "confirmed_transcript_hash" field in a GroupContext object
represents a transcript over the whole history of MLSPlaintext Commit
messages, up to the confirmation tag field in the current
MLSPlaintext message.  The confirmation tag is then included in the
transcript for the next epoch.  The interim transcript hash is passed
to new members in the GroupInfo struct, and enables existing members
to incorporate a Commit message into the transcript without having to
store the whole MLSPlaintextCommitAuthData structure.
Paragraph (version B):
The field "confirmation_tag" MUST be present if "content_type" equals
commit.  Otherwise, it MUST NOT be present.
Paragraph (version A):
The "signature" field in an MLSPlaintext object is computed using the
signing private key corresponding to the credential at the leaf of
the tree indicated by the sender field.  The signature covers the
plaintext metadata and message content, which is all of MLSPlaintext
except for the "signature" and "membership_tag" fields.  If the
sender is a member of the group, the signature also covers the
GroupContext for the current epoch, so that signatures are specific
to a given group and epoch.
Paragraph (version B):
The "signature" field in an MLSPlaintext object is computed using the
signing private key corresponding to the credential at the leaf of
the tree indicated by the sender field.  The signature covers the
plaintext metadata and message content, which is all of MLSPlaintext
except for the "signature", the "confirmation_tag" and
"membership_tag" fields.  If the sender is a member of the group, the
signature also covers the GroupContext for the current epoch, so that
signatures are specific to a given group and epoch.
Paragraph (version A):
Construct an MLSPlaintext object containing the Commit object.
Use the "commit_secret" and the "psk_secret" to advance the key
schedule and compute the "confirmation_tag" value in the
MLSPlaintext.  Sign the MLSPlaintext using the current epoch's
GroupContext as context.
Paragraph (version B):
Construct an MLSPlaintext object containing the Commit object.
Sign the MLSPlaintext using the current epoch's GroupContext as
context.  Use the signature, the "commit_secret" and the
"psk_secret" to advance the key schedule and compute the
"confirmation_tag" value in the MLSPlaintext.