Hi Devon
I support adoption
On Fri, Apr 26, 2024 at 7:38 PM Andrei Popov wrote:
> I support adoption.
>
> Cheers,
>
> Andrei
>
> -Original Message-
> From: TLS On Behalf Of Watson Ladd
> Sent: Friday, April 26, 2024 7:13 PM
> To: Devon O'Brien
> Cc: tls@ietf.org; Bob Beck
> Subject:
Hi Dennis
Admittedly, I'm not understanding how this extension enables government
coercion. It seems like, with or without this extension, the path is still
the same: you'd need to force a browser to ship with a government-issued CA
installed. Nothing about this makes that easier. It /is/ somewhat
hile
clients that don't will not advertise support for this root, and with TE we
can support both.
On Tue, Apr 30, 2024 at 3:57 AM Dennis Jackson wrote:
> Hi Brendan, Bas,
> On 30/04/2024 05:17, Brendan McMillion wrote:
>
> It seems like, with or without this extension, the
>
> This doesn't apply in case we're distrusting a CA because it's failed. In
> 9.1 we're rotating keys. As I laid out in my initial mail, we can already
> sign the new root with the old root to enable rotation. There's no size
> impact to up-to-date clients using intermediate suppression or abridg
>
> What point in this process depends on Trust Expressions - that is to say,
> at what point does a browser decide that the government CA is acting
> differently enough from the other CAs in its root store that it’s willing
> to fragment or bifurcate its trust store, and after that point, how does
pushing out
server-side support would be a substantial challenge. Not speaking for
Google, but I believe their intention /is/ to put in the substantial work
to make server-side TE support ubiquitous, such that it would be a minor
ACME config change
On Fri, May 24, 2024 at 4:00 PM Brendan McMillion <
assume that there will be no
configurable or easily-gameable way to make sure the government CA
always wins?
On Fri, May 24, 2024 at 5:15 PM Nick Harper wrote:
>
>
> On Fri, May 24, 2024 at 2:27 PM Brendan McMillion <
> brendanmcmill...@gmail.com> wrote:
>
>> In your lat
I'm not sure that this is a productive framing: "we’re really asking for a
verdict on trust negotiation as a mechanism". Trust anchor negotiation is
already deployed. It takes the form of chain building, cross signing,
and/or client fingerprinting. At the interim, the presenters went through
many o
I support adoption
I still like the framing I gave in my last email: The current solution to
trust anchor agility is path building / cross-signing. So the question is
whether an incremental improvement on path building is feasible, or if
Something Else is needed. I firmly believe that path buildin
