On 22/07/2024 16:06, Salz, Rich wrote:
I agree adding a new API for T.E. which applications could opt in to
would be fine. But could T.E. ever be enabled by default without
breaking the existing API and requiring application changes?
Yes it could. For example, you’d have to add meta-data iden
Internet-Draft draft-ietf-tls-svcb-ech-03.txt is now available. It is a work
item of the Transport Layer Security (TLS) WG of the IETF.
Title: Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings
Authors: Ben Schwartz
Mike Bishop
Erik Nygren
Name:
On 21/07/2024 18:09, Kyle Nekritz wrote:
Do you see differences with trust negotiation, or in the specific negotiation
mechanisms that are being proposed? Or would you have similar concerns if, say,
we didn't already have named group negotiation, and were discussing adding that
right now?
M
I agree that I didn’t provide a comprehensive answer, only that it was
possible, perhaps one API at a time. So maybe that addresses many legacy apps.
But you are totally right that the surface area is MUCH bigger than that.
___
TLS mailing list -- tls@
I don't think its possible to go one API / method at a time. If we want
to turn on a feature by default, it has to either be non-backwards
compatible or not break any existing API.
This is a problem for Trust Expressions because exposing the TLS
certificate to the application is a major part o
I don't think its possible to go one API / method at a time. If we want to turn
on a feature by default, it has to either be non-backwards compatible or not
break any existing API.
I think I agree with you, or at least as far as saying that we really need to
hear from implementors as to the fea
On Tue, Jul 23, 2024, 11:04 AM Salz, Rich
wrote:
> I don't think its possible to go one API / method at a time. If we want to
> turn on a feature by default, it has to either be non-backwards compatible
> or not break any existing API.
>
> I think I agree with you, or at least as far as saying th
Applications that don't support aren't worse off because other applications can
use a newer PKI with fewer problems.
I think the point is that it is unlikely this “better PKI changes” come for
free without detailed understanding on the part of app developers
On 23/07/2024 11:08, Watson Ladd wrote:
Applications that don't support aren't worse off because other
applications can use a newer PKI with fewer problems.
The sub-thread Mike started has been specifically on whether we can
bring Trust Expressions to non-browser applications by default. I do
On Tue, Jul 23, 2024 at 11:10 AM Watson Ladd wrote:
> On Tue, Jul 23, 2024, 11:04 AM Salz, Rich 40akamai@dmarc.ietf.org> wrote:
>
>> I don't think its possible to go one API / method at a time. If we want
>> to turn on a feature by default, it has to either be non-backwards
>> compatible or
There has been a lot of discussion over the past few days, both in
person and on the mailing list. I want to share some thoughts on those
discussions before the meeting tomorrow.
My impression is that there is little consensus on which problems we
want to solve as a WG. Resolving this is criti
11 matches
Mail list logo
