On Fri, Oct 27, 2023 at 9:06 AM David Benjamin
wrote:
> Responses inline.
>
> On Fri, Oct 27, 2023 at 5:04 AM Michael P1 wrote:
>
>> Hi All,
>>
>> Thank you for this interesting draft, I had a couple of quick questions.
>>
>> OpenSSL has been mentioned in this thread, but I was wondering if you
I also support adoption, and am willing to contribute to text and
implementation efforts.
On Mon, Nov 6, 2023 at 6:50 PM Andrei Popov wrote:
> Likewise, I support adoption, willing to contribute text and
> implementation.
>
> Cheers,
>
> Andrei
>
> --
> *From:* TLS o
I support adoption and am willing to review.
On Tue, Dec 5, 2023 at 10:34 PM Deirdre Connolly
wrote:
> At the TLS meeting at IETF 118 there was significant support for the draft
> 'TLS 1.2 is in Feature Freeze' (
> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/) This
> call is t
On Fri, Mar 29, 2024 at 2:59 AM David Benjamin wrote:
> Regarding renaming, I'm torn. "Group" was a truly horrible rename. The names
> we pick make their way into APIs and even sometimes UI surfaces for
> developers. Every time I've plumbed TLS named groups into another system,
> I've been met
On Fri, May 24, 2024 at 2:05 PM Christian Huitema
wrote:
>
>
> On 5/23/2024 9:41 AM, David Benjamin wrote:
> > At the end of the day, the TLS components of trust expressions are
> > simply a more size-efficient form of the certificate_authorities field.
> > The rest is working through the deploym
On Fri, May 24, 2024 at 5:18 PM Brendan McMillion <
brendanmcmill...@gmail.com> wrote:
> Even with ubiquitous server-side TE support and servers configured with
>> both a ubiquitous chain and a government-issued chain, it seems to me this
>> government push for use of their CA requires a change to
On Tue, Jun 4, 2024 at 7:24 AM Martin Thomson wrote:
> On Mon, Jun 3, 2024, at 14:34, Bas Westerbaan wrote:
> > [...] We're scanning origins so that we can send a
> > supported keyshare immediately and avoid HRR (not rolled out yet.)
> > That's not just for performance, but also to deal with orig
On Thu, Jun 13, 2024 at 4:23 PM Amir Omidi wrote:
> I’ve had a lot of trouble understanding how the user agent is supposed to
> be configured with this. Maybe a browser is going to be able to do it
> easily, but how do we envision this working in openssl? Or a programming
> language?
>
> If this
I support adoption, and would be willing to review drafts and would work to
have it implemented.
On Thu, Jul 25, 2024 at 9:44 AM Sean Turner wrote:
> At the IETF 120 TLS session there was interest in adopting the Extended
> Key Update for TLS 1.3 I-D (
> https://datatracker.ietf.org/doc/draft-ts
On Thu, Jul 25, 2024 at 10:15 AM Yaroslav Rosomakho wrote:
> Thank you for the feedback, Andrei.
>
> Yes, it is intended to stay on the informational track as an extension
> to draft-ietf-tls-keylogfile-02. We tried to keep wording in line with the
> keylogfile draft - for instance in the applica
On Aug 25, 2024, at 13:56, Salz, Rich wrote:
I am opposed. Anonymous email recommendations are not how the IETF operates.I would also count myself as opposed. While I understand and am sympathetic to a reviewer possibly not wanting to get deluged in email or opinions unrelated to the task
I also believe this should move forward.
> On Sep 10, 2024, at 4:05 PM, Bas Westerbaan
> wrote:
>
> Same.
>
> On Tue, Sep 10, 2024 at 11:51 PM Andrei Popov
> wrote:
> I support staying the course, continuing work on the key share prediction
> draft and allocating the code point.
> Cheers,
Thanks for this Sean.
On Fri, Oct 25, 2024 at 6:31 AM Sean Turner wrote:
> Hello list,
>
> The TLS list is infamous in that it is regarded by some as [insert your
> descriptive word; where the chairs have heard the following words used:
> noxious, toxic, unwelcoming, and rude]. The chairs want t
> On Sep 17, 2024, at 5:28 PM, David Benjamin
> wrote:
>
> Ah, I just noticed this text at the end of Section 7.1:
>
> > Note that in some cases it may be necessary to send an ACK which does not
> > contain any record numbers. For instance, a client might receive an
> > EncryptedExtensions
On Tue, Sep 24, 2024 at 5:12 PM David Benjamin
wrote:
> I should add, another reason to call it tls-supported-groups is that this
> is essentially what the server would have put in the supported_groups
> extension, if negotiation order in TLS were inverted. Since TLS already saw
> fit[*] to name
> On Feb 7, 2025, at 7:36 AM, Mike Shaver wrote:
>
> Hi Watson,
>
> On Thu, Feb 6, 2025 at 8:10 PM Watson Ladd wrote:
> A negotiation where what is advertised is an inherently opaque
> pointer, and where each side must maintain an idea of what that could
> mean, does not have this property. S
Rather obviously, I support adoption.
I believe TAI is a good starting point for a practical solution for the problem
we agreed was a useful thing to solve at the interim.
> On Jan 15, 2025, at 8:59 AM, Joseph Salowey wrote:
>
> At the trust tussle Interim in October we had consensus that t
> On Jan 14, 2025, at 12:20 PM, Dang, Quynh H. (Fed)
> wrote:
>
> Maybe consensus calls can only be made and completed at the in-person
> meetings ?
The problem with in-person (or even virtual at the in-person meetings) is it
then becomes even more of a pay-to-play proposition to participa
18 matches
Mail list logo
