Now that the submission deadline has passed … here’s a gentle reminder!
Cheers,
spt
> On Jun 18, 2023, at 19:25, Sean Turner wrote:
>
> The TLS WG is planning to meet at IETF 117. A 2 hour slot has been requested,
> but not yet scheduled. The chairs would like to solicit input from the WG for
Hi Dennis,
I enjoyed reading this draft. I think it is well-written. Aside from some
to-be-figured-out details that have already been pointed out, it seems very
practical, which is rather nice.
The one thing that makes me frown a bit is the intended versioning scheme.
I don't think consuming iden
This email starts the working group last call for "Deprecating Obsolete Key
Exchange Methods in TLS 1.2” I-D, located here:
https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex/
The WG Last Call will end 25 July 2023 @ 2359 UTC.
Please review the I-D and submit issues and pull
> This email starts the working group last call for "Deprecating Obsolete Key
> Exchange Methods in TLS 1.2” I-D, located here:
>. https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex
Three minor issues and a question.
Consider saying once, early.in the document, that this do
On 11/07/2023 01:00, Eric Rescorla wrote:
My sense is that we would be better off getting the data from CCADB,
as CAs will have a clear incentive to populate it, as their customers
will get better performance.
However, I think this is a question the WG is well suited to resolve
and that we c
On 11/07/2023 15:48, Thom Wiggers wrote:
I enjoyed reading this draft. I think it is well-written. Aside from
some to-be-figured-out details that have already been pointed out, it
seems very practical, which is rather nice.
Thanks!
The one thing that makes me frown a bit is the intended vers
On Tue, Jul 11, 2023 at 12:45 PM Dennis Jackson wrote:
> On 11/07/2023 15:48, Thom Wiggers wrote:
>
> > I enjoyed reading this draft. I think it is well-written. Aside from
> > some to-be-figured-out details that have already been pointed out, it
> > seems very practical, which is rather nice.
>
Hi Ilari,
On 10/07/2023 20:19, Ilari Liusvaara wrote:
What does "Note that the connection will fail regardless even if this
step is not taken as neither certificate validation nor transcript
validation can succeed." mean? TLS certificate compression does not
do anything special with transcript,
On 11/07/2023 21:17, Eric Rescorla wrote:
I wouldn't want to 'permanently' encode the root programs, CT
trusted log lists or end entity compressed extensions for example.
Arguably it will be necessary to encode the database in the final RFC.
Otherwise, you have what is effectively a normative
On Tue, Jul 11, 2023 at 2:09 PM Dennis Jackson
wrote:
> On 11/07/2023 21:17, Eric Rescorla wrote:
>
> I wouldn't want to 'permanently' encode the root programs, CT
> trusted log lists or end entity compressed extensions for example.
>
>
> Arguably it will be necessary to encode the database in th
Thanks Dennis. Your answers make sense.
Digging a little deeper on the benefit of compressing (a la Abridged Certs
draft) the leaf cert or not. Definitely this draft improves vs plain
certificate compression, but I am trying to see if it is worth the complexity
of pass 2. So, section 4 shows a
Hi Dennis,
Spinning up a new thread since this is a different topic.
Section 5.1 talks about the dictionary versioning approach and suggests an
annual cadence is enough. The issue of an up-to-date cache was a big concern
for the ICA Suppression draft, and rightfully so. A stale dictionary doe
Hi Dennis,
One more topic for general discussion.
The abridged certs draft requires a server who participates and fetches
dictionaries in order to make client connections faster. As Bas has pointed out
before, this paradigm did not work well with OSCP staples in the past. Servers
did not chose
13 matches
Mail list logo
