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
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
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 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
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
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 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@
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
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 identifying the
‘directory of certs’ that are
On 22/07/2024 12:28, Ilari Liusvaara wrote:
I don't see TE requiring breaking API changes on client: API that lets
one add a set of (pseudo) trust anchors plus TE advertisement for those
should work?
I agree adding a new API for T.E. which applications could opt in to
would be fine. But could
On Mon, Jul 22, 2024 at 11:27:37AM -0700, Dennis Jackson wrote:
> On 22/07/2024 11:00, Mike Shaver wrote:
>
> For example, Trust Anchors requires the TLS Library to have access to
> additional DNS records, which either the application needs to provide or the
> TLS Library needs to fetch itself - n
On 22/07/2024 11:00, Mike Shaver wrote:
I’m not informed enough to comment on the protocol elements of the
specific Trust Anchor proposal, but I agree that more PKI agility will
be healthy.
[...]
Trust Anchor negotiation will require configuration of both sides, but
so does cipher negotiati
On Mon, Jul 22, 2024 at 1:36 PM Dennis Jackson wrote:
> I would like to hear from the authors (or others in the TLS implementation
> community) if they think Trust Expressions / Trust Anchors can be pushed
> into non-browser endpoints by default and the work they think would be
> required to achi
On 22/07/2024 09:57, Mike Shaver wrote:
I’m not informed enough to comment on the protocol elements of the
specific Trust Anchor proposal, but I agree that more PKI agility will
be healthy.
Fundamentally, the TLS implementation community will be pushing this
agility into endpoints by default
On Mon, Jul 22, 2024 at 9:53 AM David Benjamin
wrote:
>
> Second, it assumes that the non-web PKI client does not care about the DNS
> name used. When DNS names are purely internal routing labels for API
> endpoints, etc., the exact DNS name used is not particularly significant.
> But when they a
On Mon, Jul 22, 2024 at 12:52 PM David Benjamin
wrote:
> I say sometimes because this is not always viable. It's a more indirect
> way of addressing the root issue, so there are some limitations. First,
> this requires foresight on the part of the service operator and client
> vendor. If everyone
On Mon, Jul 22, 2024 at 8:58 AM Mike Shaver wrote:
> On Sat, Jul 20, 2024 at 2:23 PM David Benjamin
> wrote:
>
>> On Sat, Jul 20, 2024, 06:13 Mike Shaver wrote:
>>
>>> In what way are these non-web systems not allowed to use other PKI
>>> models today? How would trust anchors provide that perm
On Sat, Jul 20, 2024 at 2:23 PM David Benjamin
wrote:
> On Sat, Jul 20, 2024, 06:13 Mike Shaver wrote:
>
>> In what way are these non-web systems not allowed to use other PKI
>> models today? How would trust anchors provide that permission?
>>
>
> If the same server serves both embedded/IoT tra
On 20/07/2024 11:23, David Benjamin wrote:
On Sat, Jul 20, 2024, 06:13 Mike Shaver wrote:
In what way are these non-web systems not allowed to use other PKI
models today? How would trust anchors provide that permission?
If the same server serves both embedded/IoT traffic and web bro
> Yes, if one drops usecases that are valuable to simplify stuff, later
> adding mechanism for those usecases ends up more complex than if one
> had just gone with the originally more complex solution.
>
> And it might be worse than just supporting both: The features could
> interact in bad ways. F
On Sat, Jul 20, 2024, 06:13 Mike Shaver wrote:
>
>
> On Sat, Jul 20, 2024 at 8:59 AM Ilari Liusvaara
> wrote:
>
>> Allowing various embedded and IoT stuff to migrate off of WebPKI would
>> be of immense value. Such stuff using WebPKI has been source of gigantic
>> amount of pain.
>
>
> I agree w
Have you read the second draft (draft-beck-trust-anchor-ids)?
No. That’s on me, sorry.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
On Fri, Jul 19, 2024 at 09:11:34PM -0700, Nick Harper wrote:
> On Fri, Jul 19, 2024 at 8:58 PM Salz, Rich 40akamai@dmarc.ietf.org> wrote:
>
> > Can we simplify things and solve just one problem?
> >
>
> >From my perspective, this draft does solve just one problem: how a server
> chooses a ce
On Sat, Jul 20, 2024 at 8:59 AM Ilari Liusvaara
wrote:
> Allowing various embedded and IoT stuff to migrate off of WebPKI would
> be of immense value. Such stuff using WebPKI has been source of gigantic
> amount of pain.
I agree with your second sentence very much, but I don’t understand your
f
On Fri, Jul 19, 2024 at 09:39:32PM -0700, Watson Ladd wrote:
> On Fri, Jul 19, 2024, 8:58 PM Salz, Rich
> wrote:
> >
> > 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 underst
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
33 matches
Mail list logo
