Change:
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 <del> specified in credential fielf of ClientInitKeys. </del> <ins> specified in credential field of ClientInitKeys. </ins> The ciphersuites are defined in section mls-ciphersuites. <del> 6.1.1. </del> Depending on the Diffie-Hellman group of the ciphersuite, different rules apply to private key derivation and public key verification. <ins> 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. </ins> <del> 6.1.1.1. 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). Implementations SHOULD use the approach specified in RFC7748 to calculate the Diffie-Hellman shared secret.  Implementations MUST check whether the computed Diffie-Hellman shared secret is the all- zero value and abort if so, as described in Section 6 of RFC7748.  If implementers use an alternative implementation of these elliptic curves, they SHOULD perform the additional checks specified in Section 7 of </del> <ins> 6.1.1. </ins> <del> 6.1.1.2. </del> <ins> 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). </ins> <del> 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). </del> <ins> 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). </ins> <del> Implementations SHOULD use the approach specified in RFC7748 to </del> <ins> Implementations MUST use the approach specified in RFC7748 to </ins> calculate the Diffie-Hellman shared secret.  Implementations MUST check whether the computed Diffie-Hellman shared secret is the all- zero value and abort if so, as described in Section 6 of RFC7748.  If implementers use an alternative implementation of these elliptic <del> curves, they SHOULD perform the additional checks specified in </del> <ins> curves, they MUST perform the additional checks specified in </ins> Section 7 of <del> 6.1.1.3. </del> <ins> 6.1.1.1. </ins> <del> 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. </del> <ins> 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. </ins> <del> 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 </del> <ins> 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 </ins> 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

Discussion:
This deals cleanly with groups where the private key size doesn'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.