On Fri, Jul 19, 2024, 8:58 PM Salz, Rich
wrote:
>
> I've read it before. I the main issue is that it says "trusted" a lot.
>
>
>
> Yeah, kinda snippy but not necessarily wrong.
>
>
>
> I’m a little skeptical of approaches that solve an entire problem space with
> one architecture. I’m more skepti
Hi Rich,
Have you read the second draft (draft-beck-trust-anchor-ids)? I think it's
conceptually much simpler overall and is hopefully easier to wrap one's
head around. There's no JSON structure or relying party / root program
split or anything.
The complexity of trust expressions doesn't come fr
On Fri, Jul 19, 2024 at 8:58 PM Salz, Rich wrote:
>
>- I've read it before. I the main issue is that it says "trusted" a
>lot.
>
>
>
> Yeah, kinda snippy but not necessarily wrong.
>
>
>
> I’m a little skeptical of approaches that solve an entire problem space
> with one architecture. I’m
* I've read it before. I the main issue is that it says "trusted" a lot.
Yeah, kinda snippy but not necessarily wrong.
I’m a little skeptical of approaches that solve an entire problem space with
one architecture. I’m more skeptical of enough people having the ability to
read and understand
On Fri, Jul 19, 2024 at 19:13 David Adrian wrote:
> > Isn’t the most obvious issue that more than one party have the private
> keys?
>
> This is inaccurate. Trust Expressions does not define or propose any form
> of key escrow, nor are there any changes to which parties control the
> private key
> Isn’t the most obvious issue that more than one party have the private
keys?
This is inaccurate. Trust Expressions does not define or propose any form
of key escrow, nor are there any changes to which parties control the
private keys of a connection. I encourage you (and others!) to read the
dra
The scenario where more than one party has the private keys is described in
scenario 6 [1]. The analysis of that scenario is that trust anchor
negotiation has no effect on the surveillant's ability to carry out their
goals.
1:
https://github.com/davidben/tls-trust-expressions/blob/main/surveillanc
Isn’t the most obvious issue that more than one party have the private keys?
thanks,
Rob
On Fri, Jul 19, 2024 at 18:29 Devon O'Brien wrote:
> Hi all, We’ve added a document that attempts to summarize, and offer an
> initial analysis of, several of the scenarios that have been raised in
> on-lis
Hi all, We’ve added a document that attempts to summarize, and offer an
initial analysis of, several of the scenarios that have been raised in
on-list discussions related to the possibilities that Trust Expressions (or
more broadly, Trust Anchor Negotiation) could be used to enable
surveillance, or
Hiya,
I still need to re-read the trust expressions docs, though
my sympathy remains with Dennis' arguments so far.
That said, and independent from the rest of the discussion,
FWIW I don't think the particular argument below is sound.
On 20/07/2024 00:05, Ryan Hurst wrote:
It is also worth no
I think this highlights the importance of TLS as a specification used on
the web (versus being used an arbitrary protocol between two endpoints)
being explicit about what assumptions it is making about how root programs
are operated, and how the choices of those root programs manifest for
users. I
The risks of eIDAS did not come from the existence of a trust list, nor
would they have been amplified by server adoption or negotiation mechanisms
for the trust list. The existence of a trust anchor negotiation mechanism
such as Trust Expressions does not change the fact that the security risk
con
12 matches
Mail list logo
