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,
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
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
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, 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
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 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 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, 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
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
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
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
12 matches
Mail list logo