jiebi/CodeConvo huggingface dataset:
Code change:
signature, the Attester Identity, and the Handle, and then appraises the Claims.  Appraisal procedures are application-specific and can be conducted via comparison of the Claims with corresponding Reference <del> Claims, such as Reference Integrity Measurements.  The final output </del> <ins> Values, such as Reference Integrity Measurements.  The final output </ins> of the Verifier are Attestation Results.  Attestation Results constitute new Claim Sets about the properties and characteristics of an Attester, which enables Relying Parties, for example, to assess an

Related discussion:
text: This is because an Attesting Environment should not be distinguishable and the DAA credential which represents the Attesting Environment is randomised each time it used. Comment > In my understanding, here says that the DAA credential identities the Attesting Environment. Compared with the description in the "Attester Identity" part, what does the DAA credential represent actually? Reference Claims ('refClaims') mandatory Reference Claims are components of Reference Values as defined in [I-D.ietf-rats-architecture]. [Editor's Note: Definition might become obsolete, if replaced by Reference Values. Is there a difference between Claims and Values here? Analogously, why is not named Reference Claims in the RATS arch?] Comment > I suggest using Reference Values to keep consistent with the RATS arch. Reference Claims are used to appraise the Claims received from an Attester via appraisal by direct comparison. Comment > "Direct comparison" isn't the correct expression, the comparison can have other rules. Claim Selection ('claimSelection'): optional A statement that represents a (sub-)set of Claims that can be created by an Attester. Claim Selections can act as filters that can specify the exact set of Claims to be included in Evidence. An Attester MAY decide whether or not to provide all Claims as requested via a Claim Selection. Comment > The "all Claims" may be ambiguous, I'd like to double check, does it refer to all Claims that the Attester can create or refer to all Claims requested in the Claim Selection? Section 8.1 Challenge/Response Remote Attestation Comment > In the sequence diagram, some elements in the bracket are not defined in the "Information Elements" section, such as targetEnvironment, collectedClaims, eventLog. Should these elements be defined? Section 9 Additional Application-Specific Requirements Depending on the use cases covered, there can be additional requirements. An exemplary subset is illustrated in this section. Comment > Here starts to talk about "additional requirements", but I wonder there is no other places in this draft talking about requirement, so what are the basic requirements? Regards & Thanks! Wei Pan
Code change:
simply copy all fields except the "leaf_secret" from its GroupState object. <del> [[ OPEN ISSUE: The Welcome message needs to be sent encrypted for the new member.  This should be done using the public key in the UserInitKey, either with ECIES or X3DH. ]] </del> [[ OPEN ISSUE: The Welcome message needs to be synchronized in the same way as the Add.  That is, the Welcome should be sent only if the Add succeeds, and is not in conflict with another, simultaneous Add.

Related discussion:
text: This does not handle the removal of DH uses instead of KEM which will be done as part of Issue / PR ...
I would be happier if this PR were moving the draft to use draft-barnes-cfrg-hpke, which is one of the changes I had in mind for -04. Do you think that's premature?
This text is wrong:
This could also be addressed by using draft-barnes-cfrg-hpke.
This has been fixed by
Enable, e.g., P-256 with both AES-GCM and ChaChaPoly Re-use code points from TLS
We should discuss that today
Code change:
section is bundled into another m= section, it still MUST NOT contain any ICE credentials. <del> If the m= section is not bundled into another m= section, an "a=rtcp" attribute line MUST be added with of the default RTCP candidate, as indicated in RFC5761, Section 5.1.3. </del> <ins> If the m= section is not bundled into another m= section, its "a=rtcp" attribute line MUST be filled in with the port and address of the default RTCP candidate, as indicated in RFC5761, Section 5.1.3.  If no RTCP candidates have yet been gathered, dummy values MUST be used, as described in the initial offer section above. </ins> If the m= section is not bundled into another m= section, for each candidate that has been gathered during the most recent gathering

Related discussion:
text: o If the m= section is not bundled into another m= section, an "a=rtcp" attribute line MUST be added with of the default RTCP candidate, as indicated in [RFC5761], Section 5.1.3.
Code change:
certificate. If the revocation succeeds, the server responds with status code 200 <del> (OK).  If the revocation fails, the server returns an error. </del> <ins> (OK).  If the revocation fails, the server returns an error.  For example, if the certificate has already been revoked the server returns an error response with status code 400 (Bad Request) and type "urn:ietf:params:acme:error:alreadyRevoked". </ins> 8.

Related discussion:
text: NAME This definitely needs to be reviewed.
This looks good to me.
I like the idea of a special compound error type to indicate that the subproblems field is used.
In s7.6, it seems like we should indicate what error is returned: If the revocation fails, the server returns an error. The draft this nicely in many others places in the draft.
I mentioned this earlier on the mailing list, but it did not receive any feedback: as a ACME client developer, I would like to be able to distinguish between errors which do not require user interaction (that would be "certificate is already revoked, so can't revoke it again"), and ones where the user must be warned that the operation did not succeed ("certificate could not be revoked", "bad credentials", etc.). This is currently only possible with server-specific ugly hacks (for example, returns this information, but other servers might return it differently or this might change in later versions of Boulder as it is not specified).
This is a good idea, sorry for missing it earlier. NAME - Do you have any thoughts on other cases besides "already revoked" that would (a) not require user interaction and (b) not be covered by other current error codes? NAME - Would you mind making a PR to add an error code (and anything else that NAME comes up with), and note it in the revocation section?
I thought of one to consider in :
It looks like Boulder uses 404 and a generic malformed problem type for this case: URL URL
NAME So far I couldn't think of anything else. I'm totally happy with :-)
Fixed by
:+1: Thanks!
Code change:
as defined in RFC5245, Section 4.1.1, unless it has been marked as bundle-only. <del> Or, if the ICE ufrag and password values have changed, trigger the ICE Agent to start an ICE restart and begin gathering new candidates for the media section, as defined in RFC5245, Section 9.1.1.1, unless it has been marked as bundle-only. </del> <ins> Or, if the ICE ufrag and password values have changed, and it has not been marked as bundle-only, trigger the ICE Agent to start an ICE restart, and begin gathering new candidates for the media section as described in RFC5245, Section 9.1.1.1.  If this description is an answer, also start checks on that media section as defined in RFC5245, Section 9.3.1.1. </ins> If the media section proto value indicates use of RTP:

Related discussion:
text: NAME removed the dangerous text.
Stil LGTM
Consider the following sequence of actions: setRemoteDescription(offerwithicerestart); addIceCandidate(candidate); setLocalDescription(answerwithicerestart); As issue describes, when the remote peer has set an offer with an ICE restart, but has not yet set an answer, it's doing ICE processing for both the new and old "generations" simultaneously (assuming we go that route). So, is this a candidate for the new or old generation? If "old", then it can be applied immediately. Otherwise, it should be queued and only applied after setting the local description, since the local description is what triggers the ICE restart. Of course, there's a separate issue, which is that there's no way of telling which "generation" the candidate applies to. One proposed way of fixing this is to trickle a ufrag/password along with the candidate. Another way would be to queue the candidates from the "old generation" before signaling them, and only signal them after rolling back the local description. If instead of rolling back the local description, an answer is applied, these queued old candidates would be discarded. This way, once a candidate is signaled, it unambiguously applies to only the newest generation. Note that the "candidate" could also be an end-of-candidates indication, and the same reasoning applies.
Honghai already has considered how to associate candidates with ufrag/pwds. However, I think in the absence of such markings, the candidate should be associated with the new generation, since the offer specified ICE restart and the candidate followed the offer.
I agree. Thus, if an endpoint gathers a candidate for an old generation (and doesn't have a mechanism to associate it with a ufrag/pwd), it should only signal the candidate if and when the local description that triggered the ICE restart gets rolled back. That's what I was trying to explain in the second-to-last paragraph.
In ICE, we agreed to have a ufrag parameter on the candidate. Where that parameter goes is still TBD; it could be in a=candidate or on RTCIceCandidate. But this makes it clear what the JSEP implementation should do in this case.
The ufrag parameter would need to apply to a=end-of-candidates as well.
This is good news.
Code change:
as defined in RFC5245, Section 4.1.1, unless it has been marked as bundle-only. <del> Or, if the ICE ufrag and password values have changed, trigger the ICE Agent to start an ICE restart and begin gathering new candidates for the media section, as defined in RFC5245, Section 9.1.1.1, unless it has been marked as bundle-only. </del> <ins> Or, if the ICE ufrag and password values have changed, and it has not been marked as bundle-only, trigger the ICE Agent to start an ICE restart, and begin gathering new candidates for the media section as described in RFC5245, Section 9.1.1.1.  If this description is an answer, also start checks on that media section as defined in RFC5245, Section 9.3.1.1. </ins> If the media section proto value indicates use of RTP:

Related discussion:
text: But now we need to go back to the drawing board with trickling end-of-candidates. If the ufrag needs to be trickled, we can't just trickle a "null" candidate. And we can't trickle a single special candidate with a ufrag, because different media descriptions could have different ufrags.
:-/ Perhaps we could generate individual end-of-candidates objects, followed by a null for backcompat. The null would serve as an implicit end-of-candidates for the current ufrag, but new apps would never use the null.
I think I lean towards having the trickle candidates strongly tied to a ufrag/pwd.
To provide an update on this issue: I think we still want to clarify that if there's a pending ICE restart initiated by the remote peer, any remote candidates from the new "ICE negotiation session" should be queued and only processed by the local ICE agent once the stable signaling state is reached. I don't think this can go in the trickle ICE spec, because trickle ICE has no concept of a pending ICE restart (it's a consequence of having the ability to roll back an ICE restart offer). Also, last I heard the decision was to trickle the ufrag and mid along with end-of-candidates indications. So the second paragraph of the section will need to be changed to reflect this; it's no longer one indication "for all media descriptions in the last remote description".
I've dealt with the second paragraph in PR . The first seems mostly like a "can't happen" to me. As an offerer, you should not be receiving candidates before the answer (that indicates a signaling channel reordering issue). I suppose in principle as an answerer you could receive ice candidates while thinking about the offer, but I think that the answer there is you just discard them.
See also
Code change:
entire certificate and the delegated credential, cannot. Each delegated credential is bound to a specific signature <del> algorithm for use use in the TLS handshake (RFC8446 section 4.2.3).  This prevents them from being used with other, perhaps unintended signature algorithms. </del> <ins> algorithm for use in the TLS handshake (RFC8446 section 4.2.3). This prevents them from being used with other, perhaps unintended signature algorithms.  The signature algorithm bound to the delegated credential can be chosen independantly of the set of signature algorithms supported by the end-entity certificate. </ins> 3.2.

Related discussion:
text: Addresses .
.Add some additional text to highlight that sig on server cert and DC can be different. from . Hi Sean, Thanks for the follow-up. I refreshed my memory as much as I could. Please see my responses in line. Yours, Daniel Sean Turner wrote: I think I would rather take the structure: 1 - Use case 2 - Problem description 3 - Solution I am fine with whatever fits best to you. Server operators often deploy TLS termination services in locations such as remote data centers or Content Delivery Networks (CDNs) where it may be difficult to detect key compromises. Short-lived certificates may be used to limit the exposure of keys in these cases. However, short-lived certificates need to be renewed more frequently than long-lived certificates. If an external CA is unable to issue a certificate in time to replace a deployed certificate, the server would no longer be able to present a valid certificate to clients. With short-lived certificates, there is a smaller window of time to renew a certificates and therefore a higher risk that an outage at a CA will negatively affect the uptime of the service. Typically, a TLS server uses a certificate provided by some entity other than the operator of the server (a "Certification Authority" or CA) [RFC8446 ] [RFC5280 ]. This organizational separation makes the TLS server operator dependent on the CA for some aspects of its operations, for example: Whenever the server operator wants to deploy a new certificate, it has to interact with the CA. The server operator can only use TLS signature schemes for which the CA will issue credentials. To reduce the dependency on external CAs, this document proposes a limited delegation mechanism that allows a TLS peer to issue its own credentials within the scope of a certificate issued by an external CA. These credentials only enable the recipient of the delegation to speak for names that the CA has authorized. Furthermore, this mechanism allows the server to use modern signature algorithms such as Ed25519 [RFC8032 ] even if their CA does not support them. We will refer to the certificate issued by the CA as a "certificate", or "delegation certificate", and the one issued by the operator as a "delegated credential" or "DC". I think my concern has been clarified by Ilari. It was resolved by your b). I am fine with both text. works for me.
Code change:
entire certificate and the delegated credential, cannot. Each delegated credential is bound to a specific signature <del> algorithm for use use in the TLS handshake (RFC8446 section 4.2.3).  This prevents them from being used with other, perhaps unintended signature algorithms. </del> <ins> algorithm for use in the TLS handshake (RFC8446 section 4.2.3). This prevents them from being used with other, perhaps unintended signature algorithms.  The signature algorithm bound to the delegated credential can be chosen independantly of the set of signature algorithms supported by the end-entity certificate. </ins> 3.2.

Related discussion:
text: The text does not address my concern and will recap my perspective of the discussion. My initial comment was that the reference [KEYLESS] points to a solution that does not work with TLS 1.3 and currently the only effort compatible with TLS 1.3 is draft-mglt-lurk-tls13. I expect this reference to be mentioned and I do not see it in the text proposed text. If the intention with [KEYLESS] is to mention TLS Handshake Proxying techniques, then I argued that other mechanisms be mentioned and among others draft-mglt-lurk-tls12 and draft-mglt-lurk-tls13 that address different versions of TLS. This was my second concern and I do not see any of these references being mentioned. The way I understand your response is that the paper pointed out by [KEYLESS] is not Cloudflare's commercial product but instead a generic TLS Handshake proxying and that you propose to add a reference to an academic paper that discusses the LURK extension for TLS 1.2. I appreciate that other solutions - and in this case LURK, are being considered. I am wondering however why draft-mglt-lurk-tls12 is being replaced by an academic reference [REF2] and why draft-mglt-lurk-tls13 has been omitted. It seems that we are trying to avoid any reference of the work that is happening at the IETF. Is there anything I am missing ? My suggestion for the text OLD: (e.g., a PKCS interface or a remote signing mechanism [KEYLESS]) NEW: (e.g., a PKCS interface or a remote signing mechanism such as [draft-mglt-lurk-tls13] or [draft-mglt-lurk-tls12] ([LURK-TLS12]) or [KEYLESS]) with [KEYLESS] Sullivan, N. and D. Stebila, "An Analysis of TLS Handshake Proxying", IEEE TrustCom/BigDataSE/ISPA 2015, 2015.
Code change:
entire certificate and the delegated credential, cannot. Each delegated credential is bound to a specific signature <del> algorithm for use use in the TLS handshake (RFC8446 section 4.2.3).  This prevents them from being used with other, perhaps unintended signature algorithms. </del> <ins> algorithm for use in the TLS handshake (RFC8446 section 4.2.3). This prevents them from being used with other, perhaps unintended signature algorithms.  The signature algorithm bound to the delegated credential can be chosen independantly of the set of signature algorithms supported by the end-entity certificate. </ins> 3.2.

Related discussion:
text: [LURK-TLS12] Boureanu, I., Migault, D., Preda, S., Alamedine, H.A., Mishra, S. Fieau, F., and M. Mannan, "LURK: Server-Controlled TLS Delegation”, IEEE TrustCom 2020, URL, 2020. [draft-mglt-lurk-tls12] IETF draft [draft-mglt-lurk-tls13] IETF draft It is unclear to me what is generic about the paper pointed by [KEYLESS] or [REF1]. In any case, for clarification, the paper clearly refers to Cloudflare commercial products as opposed to a generic mechanism, and this will remain whatever label will be used as a reference. Typically, Cloudflare co-authors the paper appears 12 times in the 8 page paper. The contribution section mentions: """ Our work focuses specifically on the TLS handshake proxying system implemented by CloudFlare in their Keyless SSL product [6], [7] """ The methodology mentions says: """ We tested TLS key proxying using CloudFlare’s implementation, which was implemented with the following three parts: """ """ The different scenarios were set up through CloudFlare’s control panel. In the direct handshake handshake scenario, the site is set up with no reverse proxy. In the scenario where the key is held by the edge server, the same certificate that was used on the origin is uploaded to CloudFlare and the reverse proxy is enabled for the site. """ Cloudflare appears in at least references URL CloudFlare Inc., “CloudFlare Keyless SSL,” Sep. 2014, URL N. Sullivan, “Keyless SSL: The nitty gritty technical details,” Sep. 2014, URL works for me. works for me seems clearer. I suspect earlier clarifications addressed this. thanks that it way clearer. Daniel Migault Ericsson
Code change:
A short-lived HPKE key pair used to introduce a new client to a group.  Initialization keys are published for each client <del> (UserInitKey). </del> <ins> (ClientInitKey). </ins> A secret that represent a member's contribution to the group secret (so called because the members' leaf keys are the leaves in

Related discussion:
text: Overall, this seems OK. Just using "InitKey" would be clear and less wordy.
I tried this and that led people to confuse and
Here's the Weekly Digest for : - - Last week 5 issues were created. Of these, 1 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by - - Last week, 9 pull requests were created, updated or merged. Last week, 3 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 5 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 8 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
These keys are Client one-time use keys, so "UserInitKey" seems like a strange name.
I'm fine with ClientInitKey, as long as a client is not only a physical endpoint. Changes in the architecture doc should make this clear soon.
Code change:
observation point and the receiver ("downstream loss") cannot be reliably estimated. <del> 3.7. </del> <ins> 3.8. </ins> QUIC explicitly exposes which side of a connection is a client and which side is a server during the handshake.  In addition, the

Related discussion:
text: Re SNI and ALPN: we can certainly point at the work in progress in TLS that will encrypt this information, but IMO the document should describe the current state of the world. I've just added something pointing to the SNI encryption document; while it seems that the tunneling technique described there could pretty clearly be applied to ALPN fronting as well, is there a reference for encrypting ALPN we can use here that doesn't leave details as an exercise for the reader?
I would actually prefer to describe the wire image of TLS and associated protocols in a separate document and just point to it because that's actually not only applicable for quic
I don't have a reference for encrypting ALPN. We don't have one. Maybe I should write one... On the plus side, it's something that benefits from the same techniques as SNI (and less likely to cause deployment issues, though that is only because we haven't ossified around it as much). As for the general point about now vs. later. One of the things we've tried to do is be very clear about what the invariants are, or what promises we are making. It's not the same thing as true ossification defense, but if we make it clear what we are committing to, maybe we won't have people relying on stuff we might want to change.