jiebi/CodeConvo huggingface dataset:
Change controller: n/a <del> 4.  References </del> <ins> 3. Security requirements for both media type and media type suffix registrations are discussed in Section 4.6 of MEDIATYPE. </ins> <del> 4.1.  URIs </del> <ins> 4. This specification defines the following new Internet media types MEDIATYPE. IANA has updated the "Media Types" registry at https://www.iana.org/assignments/media-types [3] with the registration information provided below. 5.  References 5.1.  URIs </ins> [1] https://mailarchive.ietf.org/arch/browse/httpapi/ [2] https://github.com/ioggstream/draft-polli-rest-api-mediatypes <ins> [3] https://www.iana.org/assignments/media-types </ins>
service, defines the types of credentials which may be used in a deployment and provides methods for: <del> Issuing new credentials, </del> <ins> Issuing new credentials with a relevant credential lifetime, </ins> <del> Validating a credential against a reference identifier, and </del> <ins> Validating a credential against a reference identifier, </ins> Validating whether or not two credentials represent the same <del> client. </del> <ins> client, and Optionally revoking credentials which are no longer authorized. </ins> A *Delivery Service*, described fully in delivery-service, provides methods for:
When, and under what circumstances, a reinitialization proposal is allowed. <del> When proposals from external senders are allowed. </del> <ins> When proposals from external senders are allowed and how to authorize those proposals. When external joiners are allowed and how to authorize those external commits. Which other proposal types are allowed. A policy of when members should commit pending proposals in a group. </ins> <del> When external joiners are allowed. </del> <ins> A policy of how to protect and share the GroupInfo objects needed for external joins. </ins> A policy for when two credentials represent the same client.  Note that many credentials may be issued authenticating the same
setting, HSMs and secure enclaves can be used to protect signature keys. <ins> 6.6. Various academic works have analyzed MLS and the different security guarantees it aims to provide.  The security of large parts of the protocol has been analyzed by [BBN19] (draft 7), [ACDT21] (draft 11) and [AJM20] (draft 12). Individual components of various drafts of the MLS protocol have been analyzed in isolation and with differing adversarial models, for example, [BBR18], [ACDT19], [ACCKKMPPWY19], [AJM20] and [ACJM20] analyze the ratcheting tree as the sub-protocol of MLS that facilitates key agreement, while [BCK21] analyzes the key derivation paths in the ratchet tree and key schedule.  Finally, [CHK19] analyzes the authentication and cross-group healing guarantees provided by MLS. </ins> 7. <ins> ACDT19: https://eprint.iacr.org/2019/1189 ACCKKMPPWY19: https://eprint.iacr.org/2019/1489 ACJM20: https://eprint.iacr.org/2020/752 AJM20: https://eprint.iacr.org/2020/1327 ACDT21: https://eprint.iacr.org/2021/1083 AHKM21: https://eprint.iacr.org/2021/1456 CHK19: https://eprint.iacr.org/2021/137 BCK21: https://eprint.iacr.org/2021/137 BBR18: https://hal.inria.fr/hal-02425247 BBN19: https://hal.laas.fr/INRIA/hal-02425229 8. </ins> This document makes no requests of IANA.
node for which this node has a private key * Decrypt the secret value for the parent of the copath node using the private key from the resolution node * Derive secret values for ancestors of that <del> node using the KDF keyed with the decrypted secret </del> <ins> node using the KDF keyed with the decrypted secret * The recipient SHOULD verify that the received public keys agree with the public keys derived from the new node_secret values </ins> Merge the updated secrets into the tree * Replace the public keys for nodes on the direct path with the received public keys * For
9.1. <del> [[ OPEN ISSUE: Direct initialization is currently undefined.  A client can create a group by initializing its own state to reflect a group including only itself, then adding the initial members.  This has computation and communication complexity O(N log N) instead of the O(N) complexity of direct initialization. ]] </del> <ins> A group can always be created by initializing a one-member group and using adding members individually.  For cases where the initial list of members is known, the Init message allows a group to be created more efficiently. The creator of the group constructs an Init message as follows: Fetch a UserInitKey for each member (including the creator) Identify a protocol version and cipher suite that is supported by all proposed members. Construct a ratchet tree with its leaves populated with the public keys and credentials from the UserInitKeys of the members, and all other nodes blank. Generate a fresh leaf key pair for the first leaf Compute its direct path in this ratchet tree Each member of the newly-created group initializes its state from the Init message as follows: Note the group ID, protocol version, and cipher suite in use Construct a ratchet tree as above Update the cached ratchet tree by replacing nodes in the direct path from the first leaf using the direct path Update the cached ratchet tree by replacing nodes in the direct path from the first leaf using the information contained in the "path" attribute The update secret for this interaction, used with an all-zero init secret to generate the first epoch secret, is the "path_secret[i+1]" derived from the "path_secret[i]" associated to the root node.  The members learn the relevant path secrets by decrypting one of the encrypted path secrets in the DirectPath and working back to the root (as in normal DirectPath processing). [[ OPEN ISSUE: This approach leaks the initial contents of the tree to the Delivery Service, unlike the sequential-Add case. ]] [[ OPEN ISSUE: It might be desireable for the group creator to be able to "pre-warm" the tree, by providing values for some nodes not on its direct path.  This would violate the tree invariant, so we would need to figure out what mitigations would be necessary. ]] </ins> 9.2.
information about a client that any existing member can use to add this client to the group asynchronously. <del> A ClientInitKey object specifies what ciphersuites a client supports, as well as providing public keys that the client can use for key derivation and signing.  The client's identity key is intended to be stable throughout the lifetime of the group; there is no mechanism to change it.  Init keys are intended to be used a very limited number of times, potentially once. (see init-key-reuse).  ClientInitKeys also contain an identifier chosen by the client, which the client MUST assure uniquely identifies a given ClientInitKey object among the set of ClientInitKeys created by this client. The init_keys array MUST have the same length as the cipher_suites array, and each entry in the init_keys array MUST be a public key for the asymmetric encryption scheme defined in the cipher_suites array and used in the HPKE construction for TreeKEM. The whole structure is signed using the client's identity key.  A ClientInitKey object with an invalid signature field MUST be considered malformed.  The input to the signature computation comprises all of the fields except for the signature field. </del> <ins> A ClientInitKey object specifies a ciphersuite that the client supports, as well as providing a public key that others can use for key agreement.  The client's identity key is intended to be stable throughout the lifetime of the group; there is no mechanism to change it.  Init keys are intended to be used a very limited number of times, ideally only once.  (See init-key-reuse).  Clients MAY generate and publish multiple ClientInitKey objects to support multiple ciphersuites, or to reduce the likelihood of init key reuse. ClientInitKeys contain an identifier chosen by the client, which the client MUST assure uniquely identifies a given ClientInitKey object among the set of ClientInitKeys created by this client. The value for init_key MUST be a public key for the asymmetric encryption scheme defined by cipher_suite.  The whole structure is signed using the client's identity key.  A ClientInitKey object with an invalid signature field MUST be considered malformed.  The input to the signature computation comprises all of the fields except for the signature field. </ins> 8.
needs to initialize a GroupContext object that can be updated to the current state using the Add message.  This information is encrypted for the new member using HPKE.  The recipient key pair for the HPKE <del> encryption is the one included in the indicated ClientInitKey, corresponding to the indicated ciphersuite.  The "add_key_nonce" field contains the key and nonce used to encrypt the corresponding Add message; if it is not encrypted, then this field MUST be set to the null optional value. </del> <ins> encryption is the one included in the indicated ClientInitKey.  The "add_key_nonce" field contains the key and nonce used to encrypt the corresponding Add message; if it is not encrypted, then this field MUST be set to the null optional value. </ins> In the description of the tree as a list of nodes, the "credential" field for a node MUST be populated if and only if that node is a leaf
direct path of the new node Set the leaf node in the tree at position "index" to a new node <del> containing the public key from the ClientInitKey in the Add corresponding to the ciphersuite in use, as well as the credential under which the ClientInitKey was signed </del> <ins> containing the public key from the ClientInitKey in the Add, as well as the credential under which the ClientInitKey was signed </ins> The "update_secret" resulting from this change is an all-zero octet string of length Hash.length.
ratchet tree and the members' ClientInitKeys. The hash of a tree is the hash of its root node, which we define <del> recursively, starting with the leaves.  The hash of a leaf node is the hash of a "LeafNodeHashInput" object: </del> <ins> recursively, starting with the leaves. While hashes at the nodes are used to check the integrity of the subtrees, signatures are required to provide authentication and group agreement.  Siganatures are especially important in the case of newcomers and MUST be verified when joining.  All nodes in the tree MUST be signed to provide authentication and group agreement. </ins> <del> The content within the leaf of a ratchet tree is composed of a "ClientInitKey" when the leaf is populated.  The "info" field is equal to the null optional value when the leaf is blank (i.e., no member occupies that leaf). </del> <ins> Elements of the ratchet tree are called "RatchetNode" objects and contain optionally a "ClientInitKey" when at the leaves or an optional "ParentNode" above. </ins> <del> The intermediate nodes contain less information, the hash of a parent node (including the root) is the hash of a "ParentNodeHashInput" struct: </del> <ins> When computing the hash of a parent node AB the "ParentNodeHash" structure is used: </ins> The "left_hash" and "right_hash" fields hold the hashes of the node's <del> left and right children, respectively.  The "public_key" field holds the hash of the public key stored at this node, represented as an "optional<HPKEPublicKey>" object, which is null if and only if the node is blank. </del> <ins> left (A) and right (B) children, respectively.  The signature within the "ParentNode" is computed over the its prefix within the serialized "ParentNodeHash" struct to cover all information about the sub-tree.  The "committer_index" is required for a member to determine the signing key needed to perform the signature verification. To compute the hash of a leaf node is the hash of a "LeafNodeHash" object: Note that unlike a ParentNode, a ClientInitKey already contains a signature. </ins> 7.4.
the "tree" array divided by two. Construct a new group state using the information in the GroupInfo <del> object.  The new member's position in the tree is "index", as defined above. </del> <ins> object and verify the integrity of the tree using the "tree_hash". The new member's position in the tree is "index", as defined above. </ins> Identify the lowest node at which the direct paths from "index" and "signer_index" overlap.  Set private keys for that node and
Ciphersuites are represented with the CipherSuite type.  HPKE public keys are opaque values in a format defined by the underlying Diffie- Hellman protocol (see the Ciphersuites section of the HPKE <del> specification for more information): 6.1.1. This ciphersuite uses the following primitives: </del> <ins> specification for more information). </ins> <del> Hash function: SHA-256 </del> <ins> 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. </ins> <del> AEAD: AES-128-GCM </del> <ins> The ciphersuites are defined in section mls-ciphersuites. </ins> <del> When HPKE is used with this ciphersuite, it uses the following algorithms: KEM: 0x0002 = DHKEM(Curve25519) </del> <ins> 6.1.1. </ins> <del> KDF: 0x0001 = HKDF-SHA256 </del> <ins> Depending on the Diffie-Hellman group of the ciphersuite, different rules apply to private key derivation and public key verification. </ins> <del> AEAD: 0x0001 = AES-GCM-128 </del> <ins> 6.1.1.1. </ins> Given an octet string X, the private key produced by the Derive-Key- <del> Pair operation is SHA-256(X).  (Recall that any 32-octet string is a valid Curve25519 private key.)  The corresponding public key is </del> <ins> Pair operation is SHA-256(X) (Recall that any 32-octet string is a valid X25519 private key).  The corresponding public key is </ins> X25519(SHA-256(X), 9). Implementations SHOULD use the approach specified in RFC7748 to
curves, they SHOULD perform the additional checks specified in Section 7 of <del> 6.1.2. This ciphersuite uses the following primitives: </del> <ins> 6.1.1.2. </ins> <del> Hash function: SHA-256 AEAD: AES-128-GCM When HPKE is used with this ciphersuite, it uses the following algorithms: KEM: 0x0001 = DHKEM(P-256) </del> <ins> 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). </ins> <del> KDF: 0x0001 = HKDF-SHA256 </del> <ins> 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 </ins> <del> AEAD: 0x0001 = AES-GCM-128 </del> <ins> 6.1.1.3. </ins> 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.
D.ietf-trans-rfc6962-bis.) The _direct path_ of a root is the empty list, and of any other node <del> is the concatenation of that node with the direct path of its parent. The _copath_ of a node is the list of siblings of nodes in its direct </del> <ins> 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 </ins> path.  The _frontier_ of a tree is the list of heads of the maximal full subtrees of the tree, ordered from left to right. For example, in the below tree: <del> The direct path of C is (C, CD, ABCD) </del> <ins> The direct path of C is (CD, ABCD, ABCDEFG) </ins> The copath of C is (D, AB, EFG)
The path secret value for a given node is encrypted for the subtree corresponding to the parent's non-updated child, that is, the child on the copath of the leaf node.  There is one encrypted path secret <del> for each public key in the resolution of the non-updated child.  In particular, for the leaf node, there are no encrypted secrets, since a leaf node has no children. </del> <ins> for each public key in the resolution of the non-updated child. </ins> The recipient of a path update processes it with the following steps:
unoccupied leaf, or appended to the right edge of the tree if all leaves are occupied. <del> Create an initial, partial GroupInfo object reflecting the following values: Group ID: The group ID for the group Epoch: The epoch ID for the next epoch Tree: The group's ratchet tree after the commit has been applied Prior confirmed transcript hash: The confirmed transcript hash for the current state of the group (not the provisional state) </del> Create a DirectPath using the new tree (which includes any new members).  The GroupContext for this operation uses the "group_id", "epoch", "tree", and "prior_confirmed_transcript_hash"
the "confirmation" value in the MLSPlaintext.  Sign the MLSPlaintext using the current epoch's GroupContext as context. <del> Complete the GroupInfo by populating the following fields: </del> <ins> Update the tree in the provisional state by applying the direct path </ins> <del> Confirmed transcript hash: The confirmed transcript hash including the current Commit object </del> <ins> Construct a GroupInfo reflecting the new state: </ins> <del> Interim transcript hash: The interim transcript hash including the current Commit object </del> <ins> Group ID, epoch, tree, confirmed transcript hash, and interim transcript hash from the new state </ins> <del> Confirmation: The confirmation from the MLSPlaintext </del> <ins> The confirmation from the MLSPlaintext object </ins> Sign the GroupInfo using the member's private signing key Encrypt the GroupInfo using the key and nonce derived from the <del> "init_secret" for the current epoch (see welcoming-new-members) </del> <ins> "epoch_secret" for the new epoch (see welcoming-new-members) For each new member in the group: Identify the lowest common ancestor in the tree of the new member's leaf node and the member sending the Commit Compute the path secret corresponding to the commonn ancestor node Compute an EncryptedKeyPackage object that encapsulates the "init_secret" for the current epoch and the path secret for the common ancestor. </ins> <del> For each new member in the group, compute an EncryptedKeyPackage object that encapsulates the "init_secret" for the current epoch. </del> Construct a Welcome message from the encrypted GroupInfo object and the encrypted key packages.
the new state is the "prior_confirmed_transcript_hash" in the GroupInfo object. <del> Process the "path" field in the GroupInfo to update the new group state: </del> <ins> Update the leaf at index "index" with the private key corresponding to the public key in the node. </ins> <del> Apply the DirectPath to the tree, as described in synchronizing-views-of-the-tree. </del> <ins> Identify the lowest common ancestor of the leaves at "index" and at "GroupInfo.signer_index".  Set the private key for this node to the private key derived from the "path_secret" in the KeyPackage object. </ins> <del> Define "commit_secret" as the value "path_secret[n+1]" derived from the "path_secret[n]" value assigned to the root node. </del> <ins> For each parent of the common ancestor, up to the root of the tree, derive a new path secret and set the private key for the node to the private key derived from the path secret.  The private key MUST be the private key that correspondns to the public key in the node. </ins> Use the "epoch_secret" from the KeyPackage object to generate the epoch secret and other derived secrets for the current epoch.
A hash function <del> A Diffie-Hellman finite-field group or elliptic curve group </del> <ins> A key encapsulation mechanism (KEM) </ins> An AEAD encryption algorithm A signature algorithm <del> The ciphersuite's Diffie-Hellman group is used to instantiate an HPKE I-D.irtf-cfrg-hpke instance for the purpose of public-key encryption. The ciphersuite must specify an algorithm "Derive-Key-Pair" that maps octet strings with length Hash.length to HPKE key pairs. </del> <ins> The ciphersuite's KEM used to instantiate an HPKE I-D.irtf-cfrg-hpke instance for the purpose of public-key encryption.  Each ciphersuite has a "Derive-Key-Pair" function that maps octet strings of length "Nsk" (a KEM-specific constant defined by HPKE) to HPKE key pairs. This function is defined to be HPKE's "DeriveKeyPair" function. </ins> Ciphersuites are represented with the CipherSuite type.  HPKE public <del> keys are opaque values in a format defined by the underlying Diffie- Hellman protocol (see the Ciphersuites section of the HPKE specification for more information). </del> <ins> keys are opaque values in a format defined by the underlying protocol (see the Cryptographic Dependencies section of the HPKE specification for more information). </ins> The signature algorithm specified in the ciphersuite is the mandatory algorithm to be used for signatures in MLSPlaintext and the tree
The ciphersuites are defined in section mls-ciphersuites. <del> 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. 6.1.1. 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). 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). Implementations MUST 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 MUST perform the additional checks specified in Section 7 of 6.1.2. 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. 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. (Note that this use of the identity KDF is a technicality.  The complete picture is that ECDH is employed with a non-trivial KDF because MLS does not directly use this secret for anything other than for computing other secrets.) Clients MUST validate remote public values by ensuring that the point is a valid point on the elliptic curve.  The appropriate validation procedures are defined in Section 4.3.7 of X962 and alternatively in Section 5.6.2.3 of keyagreement.  This process consists of three steps: (1) verify that the value is not the point at infinity (O), (2) verify that for Y = (x, y) both integers are in the correct interval, (3) ensure that (x, y) is a correct solution to the elliptic curve equation.  For these curves, implementers do not need to verify membership in the correct subgroup. </del> 6.2. A member of a group authenticates the identities of other