Draft: draft-ietf-mls-protocol

Commentary: This deals cleanly with groups where the private key size does n't align neatly with a hash function output size ( e.g. , X448 ) , and saves a few hash invocations by removing intermediate values . A few editorial changes are included here as well . Depends on . 
 As discussed on call , folks are comfortable with this . Ready to merge , pending 
 Please merge when get a chance .
Paragraph (version A):
The _direct path_ of a root is the empty list, and of any other node
is the concatenation of that node's parent along with the parent's
direct path.  The _copath_ of a node is the node's sibling
concatenated with the list of siblings of all the nodes in its direct
path.  The _frontier_ of a tree is the list of heads of the maximal
full subtrees of the tree, ordered from left to right.
Paragraph (version B):
The _direct path_ of a root is the empty list, and of any other node
is the concatenation of that node's parent along with the parent's
direct path.  The _copath_ of a node is the node's sibling
concatenated with the list of siblings of all the nodes in its direct
path.
Paragraph (version A):
The generator of the Commit starts by using the HPKE secret key
"leaf_hpke_secret_key" associated with the new leaf ClientInitKey
(see initialization-keys) to compute "path_secret[0]" and generate a
sequence of "path secrets", one for each ancestor of its leaf.  That
is, path_secret[0] is used for the node directly above the leaf,
path_secret[1] for its parent, and so on.  At each step, the path
secret is used to derive a new secret value for the corresponding
node, from which the node's key pair is derived.
Paragraph (version B):
The generator of the Commit starts by using the HPKE secret key
"leaf_hpke_secret" associated with the new leaf ClientInitKey (see
initialization-keys) to compute "path_secret[0]" and generate a
sequence of "path secrets", one for each ancestor of its leaf.  That
is, path_secret[0] is used for the node directly above the leaf,
path_secret[1] for its parent, and so on.  At each step, the path
secret is used to derive a new secret value for the corresponding
node, from which the node's key pair is derived.
Paragraph (version A):
The recipient SHOULD verify that the received public keys agree
with the public keys derived from the new node_secret values.
Paragraph (version B):
The recipient SHOULD verify that the received public keys agree
with the public keys derived from the new path_secret values.
Paragraph (version A):
For nodes where an updated path secret was computed in step 1,
compute the corresponding node secret and node key pair and
replace the values stored at the node with the computed values.
Paragraph (version B):
For nodes where an updated path secret was computed in step 1,
compute the corresponding node key pair and replace the values
stored at the node with the computed values.
Paragraph (version A):
The signature algorithm specified in the ciphersuite is the mandatory
algorithm to be used for the signatutes in MLSPlaintext and the tree
signatures.  It can be different from the signature algorithm
specified in credential fielf of ClientInitKeys.
Paragraph (version A):
Depending on the Diffie-Hellman group of the ciphersuite, different
rules apply to private key derivation and public key verification.
Paragraph (version A):
Given an octet string X, the private key produced by the Derive-Key-
Pair operation is SHA-256(X) (Recall that any 32-octet string is a
valid X25519 private key).  The corresponding public key is
X25519(SHA-256(X), 9).
Paragraph (version A):
Given an octet string X, the private key produced by the Derive-Key-
Pair operation is SHA-512(X) truncated to 448 bits (Recall that any
56-octet string is a valid X448 private key).  The corresponding
public key is X448(SHA-512(X), 5).
Paragraph (version A):
Given an octet string X, the private key produced by the Derive-Key-
Pair operation is SHA-256(X), interpreted as a big-endian integer.
The corresponding public key is the result of multiplying the
standard P-256 base point by this integer.
Paragraph (version A):
P-256 ECDH calculations (including parameter and key generation as
well as the shared secret calculation) are performed according to
IEEE1363 using the ECKAS-DH1 scheme with the identity map as key
derivation function (KDF), so that the shared secret is the
x-coordinate of the ECDH shared secret elliptic curve point
represented as an octet string.  Note that this octet string (Z in
IEEE 1363 terminology) as output by FE2OSP, the Field Element to
Octet String Conversion Primitive, has constant length for any given
field; leading zeros found in this octet string MUST NOT be
truncated.
Paragraph (version B):
The signature algorithm specified in the ciphersuite is the mandatory
algorithm to be used for the signatutes in MLSPlaintext and the tree
signatures.  It can be different from the signature algorithm
specified in credential field of ClientInitKeys.
Paragraph (version B):
Depending on the Diffie-Hellman group of the ciphersuite, different
rules apply to private key derivation and public key verification.
For all ciphersuites defined in this document, the Derive-Key-Pair
function begins by deriving a "key pair secret" of appropriate
length, then converting it to a private key in the required group.
The ciphersuite specifies the required length and the conversion.
Paragraph (version B):
For X25519, the key pair secret is 32 octets long.  No conversion is
required, since any 32-octet string is a valid X25519 private key.
The corresponding public key is X25519(SHA-256(X), 9).
Paragraph (version B):
For X448, the key pair secret is 56 octets long.  No conversion is
required, since any 56-octet string is a valid X448 private key.  The
corresponding public key is X448(SHA-256(X), 5).
Paragraph (version B):
For P-256, the key pair secret is 32 octets long.  For P-521, the key
pair secret is 66 octets long.  In either case, the private key
derived from a key pair secret is computed by interpreting the key
pair secret as a big-endian integer.
Paragraph (version B):
ECDH calculations for these curves (including parameter and key
generation as well as the shared secret calculation) are performed
according to IEEE1363 using the ECKAS-DH1 scheme with the identity
map as key derivation function (KDF), so that the shared secret is
the x-coordinate of the ECDH shared secret elliptic curve point
represented as an octet string.  Note that this octet string (Z in
IEEE 1363 terminology) as output by FE2OSP, the Field Element to
Octet String Conversion Primitive, has constant length for any given
field; leading zeros found in this octet string MUST NOT be
truncated.