On Thu, Jan 20, 2022 at 10:31 PM Daniel Kahn Gillmor
wrote:
> This sounds a lot like a "SHOULD BUT WE KNOW YOU WONT". Why would a
> client deliberately fail a connection when the problem might be a flaw
> with an unrelated network service or a client-specific routing failure?
>
> I think we can
On Wed 2022-01-19 16:57:07 +0200, Yaron Sheffer wrote:
> * Add a SHOULD-level requirement (for TLS 1.3 implementations,
> possibly also TLS 1.2 implementations) to fail the handshake if the
> OCSP response is missing or invalid. (As far as we can tell, RFC 8446
> is silent on this.)
This sounds a
I am not convinced that the extra effort is justified.
However, I am convinced that the proposed construction is complex.
combined_key = H(HMAC(key=H1(k1), data=2||F(k2)) xor HMAC(key=H2(k2),
data=1||F(k1)))
H1(k) = H('derive1' || k)
H2(k) = H('derive2' || k)
F(m) =
On Thu, Jan 20, 2022 at 8:41 AM Hanno Böck wrote:
> Thus even if you think OCSP stapling and the whole process of revocation
> is useless, there are still good reasons for a server operator to enable
> stapling:
> 1. It avoids an extra connection for clients to the OCSP server, thus
> making
Hi Hannes, This is not about my personal beliefs. RFC 7525 looks at certificate revocation in the context of TLS (and not only TLS for Web use but the broader ecosystem) and recommends OCSP and OCSP Stapling as the best available techniques to enable effective certificate revocation, but with
Reading the discussion so far I want to raise something to consider.
There are separate questions that shouldn't be confused:
1. Is OCSP stapling with soft-fail (absent further enforcement
mechanisms like muststaple) actually useful?
2. Should server operators enable OCSP stapling?
For 1. one
Hi Yaron,
Where do you believe OCSP will be a good fit and why?
Ciao
Hannes
From: TLS On Behalf Of Yaron Sheffer
Sent: Wednesday, January 19, 2022 3:57 PM
To: u...@ietf.org; tls@ietf.org
Subject: [TLS] OCSP in RFC7525bis
Hi,
RFC 7525 (the TLS BCP) has a section [1] with “weak”
