On Wed, Oct 25, 2023 at 02:34:08AM +, Peter Gutmann wrote:
> Andrei Popov writes:
>
> >An "I really mean it" flag. We can add these for every TLS message, not just
> >authentication-related ones. Just to make sure the peer truly is serious
> >about the TLS handshake.
>
> It really depends
Andrei Popov writes:
>An "I really mean it" flag. We can add these for every TLS message, not just
>authentication-related ones. Just to make sure the peer truly is serious
>about the TLS handshake.
It really depends on how servers react when they see client-cert-auth when
they're not expecting
Some changes from the last time this was posted:
- Apparently we got early codepoint allocation for this and I forgot about
it? Anyway the allocated codepoints are now in the draft.
- We've crisped up the motivation a bit.
One thing I'll call out is that the previous discussion mentioned one
This is similar to the case when a server is unable to use its RSA key to
sign with PSS passing (my slides for TLS WG in 2015
https://www.ietf.org/proceedings/94/slides/slides-94-tls-4.pdf , presented
by Eric), but instead this is about client keys/signatures.
I don't have a stake in this
Hi TLS,
We would like to re-introduce
https://datatracker.ietf.org/doc/draft-davidben-tls13-pkcs1/
(it's intended for the TLS WG and the Standards track, despite what the
document says at the top; we'll fix it as soon as the submission tool reopens).
In the course of TLS 1.3 deployment, it
On Tue, Oct 24, 2023 at 06:05:27PM +, Ben Schwartz wrote:
> Hi TLS,
>
> We've just uploaded a new revision of the cTLS draft. The most
> exciting change in this revision is an additional informative
> reference to Comparse [1], a new formal verification system.
> The Comparse paper includes
On Tue, Oct 24, 2023 at 04:13:48PM +, Andrei Popov wrote:
> > So it may be necessary to have the server respond with its own flag
> > to indicate that it really does want client cert auth and isn't just
> > asking for a client cert on autopilot.
>
> An "I really mean it" flag. We can add
Hi TLS,
We've just uploaded a new revision of the cTLS draft. The most exciting change
in this revision is an additional informative reference to Comparse [1], a new
formal verification system. The Comparse paper includes a security proof of
cTLS (and also TLS and MLS). This revision also
On Tue, Oct 24, 2023, 13:07 Viktor Dukhovni wrote:
> On Tue, Oct 24, 2023 at 12:54:08PM -0400, David Benjamin wrote:
>
> > Is the concern here errors or prompting? From the original email, it
> > sounded like the issue was that requesting client certificates showed
> > undesirable UI to
On Tue, Oct 24, 2023 at 12:54:08PM -0400, David Benjamin wrote:
> Is the concern here errors or prompting? From the original email, it
> sounded like the issue was that requesting client certificates showed
> undesirable UI to human-backed clients.
My concern is errors, browser UX concerts are
Is the concern here errors or prompting? From the original email, it
sounded like the issue was that requesting client certificates showed
undesirable UI to human-backed clients.
That one is a bit harder to avoid since no one is acting incorrectly per
se. Clients for humans need to ask the human
On Tue, Oct 24, 2023 at 04:11:53PM +, Andrei Popov wrote:
> > At least as a client, you can't read anything into seeing a cert request
> > from the server, it's just a standard part of the handshake, like a keyex
> > or a finished.
>
> This is exactly my argument: when a client receives a
> So it may be necessary to have the server respond with its own flag to
> indicate that it really does want client cert auth and isn't just asking for
> a client cert on autopilot.
An "I really mean it" flag. We can add these for every TLS message, not just
authentication-related ones. Just to
> At least as a client, you can't read anything into seeing a cert request from
> the server, it's just a standard part of the handshake, like a keyex or a
> finished.
This is exactly my argument: when a client receives a cert request the client
cannot satisfy, the RFC says send an empty
A few comments and nits are below but I have one high level question. Why limit
the manifest produced by root programs to trust anchors? Root programs could
produce a structure that represents CA certificates and all possible partial
paths that can be validated by a trust store as well. This
Viktor Dukhovni writes:
>I don't see in your comment anything to suggest that the flag is a no-go.
Oh, it's definitely not a no-go, just pointing out that you shouldn't read too
much into seeing a cert request from a server. In other words if the client
says "I have a cert" and the server
On Tue, Oct 24, 2023 at 02:40:35AM +, Peter Gutmann wrote:
> >Yes, but, arguably, such broken clients won't be fixed by adding new
> >extensions/flags/etc. If they do not comply with the simple RFC language that
> >exists, can we expect them to implement the new flag correctly?
>
> I would
17 matches
Mail list logo