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 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 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 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 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 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 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 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 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
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
10 matches
Mail list logo
