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 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 deployment implications to reduce server
operator burden. However, the way we
On Fri, May 24, 2024 at 06:14:00PM +0100, Dennis Jackson wrote:
>
> Trust Expressions, though intended to solve completely different problems,
> will accidentally eradicate both of these advantages. Firstly, it provides a
> nice on ramp for a new domestic trust store, mostly through the negotiatio
On Thu, May 23, 2024 at 4:14 AM Dennis Jackson wrote:
> Hi Nick,
>
> I think the issues around risk have a great deal of nuance that you're not
> appreciating, but which I've tried to lay out below. I appreciate that
> rational reasonable people can absolutely disagree on how they weigh up
> thes
Hi Ryan,
On 23/05/2024 19:01, Ryan Hurst wrote:
Regarding the concern about government-mandated adoption of root
certificates, I also care deeply about this issue. This is why I am
disappointed by the one-sided nature of the conversation. I see no
mechanism in this proposal that bypasses opera
On 23/05/2024 17:41, David Benjamin wrote:
On Thu, May 23, 2024 at 11:09 AM Dennis Jackson
wrote
This is something that I believe David Benjamin and the other
draft authors, and I all agree on. You and Nick seem to have
misunderstood either the argument or the draft.
David Be
I am joining this thread a bit late but have been following the discussion.
I want to express my support for Trust Expressions and comment on a few
points that have been made.
First, the reality is that websites already have to support multiple
certificates to accommodate both ECC and RSA. This is
On Thu, May 23, 2024 at 12:42 PM David Benjamin wrote:
>
> Of course, whether this property (whether servers can usefully pre-deploy
> not-yet-added trust anchors), which trust expressions does not have, even
> matters boils to whether a root program would misinterpret availability in
> server
Hi! Let’s clam it down some in this thread. Just a gentle reminder to keep it
professional.
Thanks,
spt
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
On Thu, May 23, 2024 at 11:09 AM Dennis Jackson wrote
>
> > I think we have to agree that Trust Expressions enables websites to
> adopt new CA chains regardless of client trust and even builds a
> centralized mechanism for doing so. It is a core feature of the design.
>
> No one has to agree to t
Hi David,
On 23/05/2024 14:07, David Adrian wrote:
There is certainly a discussion to be had about how well Trust
Expressions solves problems experienced by the HTTPS ecosystem and the
Web PKI today. However, that requires moving past repeated,
unsubstantiated claims about how Trust Expression
Hi Dennis,
There is certainly a discussion to be had about how well Trust Expressions
solves problems experienced by the HTTPS ecosystem and the Web PKI today.
However, that requires moving past repeated, unsubstantiated claims about
how Trust Expressions enables government surveillance, something
Hi Nick,
I think the issues around risk have a great deal of nuance that you're
not appreciating, but which I've tried to lay out below. I appreciate
that rational reasonable people can absolutely disagree on how they
weigh up these risks, but I think we have to agree that Trust
Expressions e
On Tue, May 21, 2024 at 4:56 PM David Benjamin
wrote:
>
> Hi Richard. Thanks for the comments! Replies inline.
>
> On Mon, May 6, 2024 at 10:23 AM Richard Barnes wrote:
>>
>> Hi all,
>>
>> Coming in late here. Appreciate the discussion so far. FWIW, here's
how I'm thinking through this:
>>
>> I
On Tue, May 21, 2024 at 3:00 PM Dennis Jackson wrote:
> This thread is now 40+ messages deep and I guess you might have not seen
> much of the previous discussion. I actually agree with much of your
> analysis, but it focused on the wrong question, as I wrote earlier in this
> thread:
>
> The que
Hi Nick,
On 21/05/2024 19:05, Nick Harper wrote:
[...]
Perhaps there are additional ways to use Trust Expressions to censor
the web that are more practical and more useful than the existing
techniques that I didn't consider. There are most certainly other
forms of domestic control of the Web
Hiya,
A slightly meta comment:
On 21/05/2024 19:05, Nick Harper wrote:
From a process perspective, considering how a technology could be abused is
important and should be addressed to a reasonable level in the RFC. I don't
see a need for this to be fully fleshed out with every possible abus
On Mon, May 20, 2024 at 7:26 AM Dennis Jackson wrote:
> Compared to the alternatives, Trust Expressions seems to solve the
> problems less effectively and introduce much greater risks. If you really
> feel the opposite is true, I would strongly encourage you to:
> b) Make a good faith attempt to
Hi Richard. Thanks for the comments! Replies inline.
On Mon, May 6, 2024 at 10:23 AM Richard Barnes wrote:
> Hi all,
>
> Coming in late here. Appreciate the discussion so far. FWIW, here's how
> I'm thinking through this:
>
> I would frame the basic problem here as follows, since I think the u
(replies inline)
On Sun, May 5, 2024 at 6:48 PM Dennis Jackson wrote:
> Hi David, Devon, Bob,
>
> I feel much of your response talks past the issue that was raised at IETF
> 118.
>
> The question we're evaluating is NOT "If we were in a very unhappy world
> where governments controlled root cert
Hi David, Devon, Bob,
Response to both your recent mails below:
On Thu, May 9, 2024 at 10:45 AM David Benjamin
wrote:
We’re particularly concerned about this server operator pain because
it translates to security risks for billions of users. If root program
actions cause server operator pain
Resending this since it seems IETF lists were broken recently (
https://www.ietf.org/blog/ietf-mailing-list-delivery-issues/). Hopefully it
works this time.
On Thu, May 9, 2024 at 10:45 AM David Benjamin
wrote:
> Hi Richard. Thanks for the comments! Replies inline.
>
> On Mon, May 6, 2024 at 10:
Resending this since it seems IETF lists were broken recently (
https://www.ietf.org/blog/ietf-mailing-list-delivery-issues/). Hopefully it
works this time.
On Thu, May 9, 2024 at 10:40 AM David Benjamin
wrote:
> (replies inline)
>
> On Sun, May 5, 2024 at 6:48 PM Dennis Jackson 40dennis-jackso
Hi all,
Coming in late here. Appreciate the discussion so far. FWIW, here's how
I'm thinking through this:
I would frame the basic problem here as follows, since I think the use
cases presented are all basically corollaries: Root store fragmentation
makes it hard for server operators to make su
24 matches
Mail list logo
