Aha, that sounds like the disconnect! One trust anchor identifier indeed
only represents a one trust anchor. And, yeah, absolutely agreed that's a
significant difference!
I'm guessing this mixup came from the talk of user agent strings in the
problem-space-focused interm? TBH, I was quite perplexe
On Sat, Feb 8, 2025 at 9:44 AM David Adrian wrote:
>
> To be clear, the client does NOT send its full list of trust anchors by
> default. There is a server-side DNS signaling mechanism that allows the
> client to pick a single anchor without sending the full set.
>
> The feedback at IETF Vancouv
To be clear, the client does NOT send its full list of trust anchors by
default. There is a server-side DNS signaling mechanism that allows the
client to pick a single anchor without sending the full set.
The feedback at IETF Vancouver was to move away from a client signals,
server selects (via tr
>
> Silly clarification: the TAI identifier is just a compact identifier
> for the root cert, like (making it up) a 4 byte identifier? So the
> client sends the entire list of root certs supported, so about 100, so
> 400 bytes?
>
> In that case I think you can inject it into an end-entity cert on
>
On Fri, Feb 7, 2025 at 9:17 AM David Benjamin wrote:
>
> On Fri, Feb 7, 2025 at 9:44 AM Mike Shaver wrote:
>>
>> Hi Watson,
>>
>> On Thu, Feb 6, 2025 at 8:10 PM Watson Ladd wrote:
>>>
>>> A negotiation where what is advertised is an inherently opaque
>>> pointer, and where each side must maintai
On Fri, Feb 7, 2025 at 12:17 PM David Benjamin
wrote:
> On Fri, Feb 7, 2025 at 9:44 AM Mike Shaver wrote:
>
>> Hi Watson,
>>
>> On Thu, Feb 6, 2025 at 8:10 PM Watson Ladd wrote:
>>
>>> A negotiation where what is advertised is an inherently opaque
>>> pointer, and where each side must maintain
On Fri, Feb 7, 2025 at 9:44 AM Mike Shaver wrote:
> Hi Watson,
>
> On Thu, Feb 6, 2025 at 8:10 PM Watson Ladd wrote:
>
>> A negotiation where what is advertised is an inherently opaque
>> pointer, and where each side must maintain an idea of what that could
>> mean, does not have this property.
> On Feb 7, 2025, at 7:36 AM, Mike Shaver wrote:
>
> Hi Watson,
>
> On Thu, Feb 6, 2025 at 8:10 PM Watson Ladd wrote:
> A negotiation where what is advertised is an inherently opaque
> pointer, and where each side must maintain an idea of what that could
> mean, does not have this property. S
I don't think there's any new argument to address, so I will just offer
a pointers into where these issues are discussed in 'Trust is
non-negotiable'.
Section 3.3 [1] looks at how trust negotiation (as an abstract
mechanism) changes incentives to divergence for existing root programs,
as well
Hi Watson,
On Thu, Feb 6, 2025 at 8:10 PM Watson Ladd wrote:
> A negotiation where what is advertised is an inherently opaque
> pointer, and where each side must maintain an idea of what that could
> mean, does not have this property. Servers have to explicitly act to
> support the new identifie
Dear David,
I have to start by apologizing. It's not until now on reading your
email that I've come to the realization of what the issues were with
at least the early negotiation proposals in a way that makes them
clearly articulateable, and I think earlier on it would have been more
fruitful for
On Thu, Feb 6, 2025 at 4:40 PM Salz, Rich wrote:
>
>
> First, to correct a misrepresentation: this draft is not a veiled attempt
> to completely diverge from the Web PKI and fragment the ecosystem.
>
>
>
> I never said that the draft is such a veiled attempt, and I don’t recall
> any other postin
First, to correct a misrepresentation: this draft is not a veiled attempt to
completely diverge from the Web PKI and fragment the ecosystem.
I never said that the draft is such a veiled attempt, and I don’t recall any
other postings saying that. I am concerned that the fragmentation is a hi
13 matches
Mail list logo
