On Wed, Jun 5, 2024 at 9:19 AM Peter Gutmann
wrote:
> Nick Harper writes:
>
> >I see no requirement in section 9 nor in section 4.2.8 requiring MTI
> curves
> >be present in the key_share extension if that extension is non-empty.
>
> Just because it's possible to rules-lawyer your way around som
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
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 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 s
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 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
Yeah, I think we will see more inadvertent logging than malicious, just as
we have seen passwords mistakenly deposited in logs for approximately as
long as we have had both logs and passwords.
One challenge with SSLKEYLOG is that there’s no way without very
system-specific inspection to detect whe
Public CAs not only add another risk, but public CAs shouldn't want to be
issuing these anyway if they are not for use with the web PKI. I agree that
it doesn't seem in scope for the IETF's work, but I'll admit that I'd love
to see more advocacy for divorcing such configurations from the public web
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
I support adoption. Cross-signing has proven a clumsy tool for managing the
introduction of new roots, and we need something better.
Mike
On Wed, Jan 15, 2025 at 11:01 AM Joseph Salowey wrote:
> At the trust tussle Interim in October we had consensus that the working
> group was interested in
It's interesting, IMO, that there is so much belief that an RFC designation
will drive so much adoption here, but it didn't seem to be the same
consensus that enshrining SSLKEYLOGFILE in an RFC might increase the number
of systems that support key exfil.
To be sure, I don't confidently know which
11 matches
Mail list logo
