Thank you all for the lively and far reaching discussion on revocation and
OCSP. Let me summarize how the authors of RFC7525-bis read the consensus - UTA
WG chairs, please chime in if you disagree.
There seems to be consensus that applications should be able to handle
certificate revocation. T
on checking- Short-lived certificates is an improvement over long-lived
certificates, but not at all a replacement for revocation checking.
Cheers,
John
From: Uta on behalf of Hannes Tschofenig
Date: Monday, 24 January 2022 at 11:32
To: Yaron Sheffer , uta@ietf.org ,
t...@ietf.org
Subject: Re
Hi Yaron,
That’s exactly my worry. I have seen OCSP being proposed in EMU (with EAP-TLS)
and also in IoT environments where it just don’t make a lot of sense to me.
Hence, I would like to understand the motivation behind it and the use cases.
Ciao
Hannes
From: Yaron Sheffer
Sent: Thursday, J
On Fri, Jan 21, 2022 at 9:52 AM Daniel Kahn Gillmor
wrote:
> I share your skepticism, but i'm still trying to salvage something
> useful -- for the purpose of defending against CA malfeasance -- from
> the mechanisms we have available.
>
Indeed, I think the goal is admirable, but I'm not sure th
Hi Ryan--
I share your skepticism, but i'm still trying to salvage something
useful -- for the purpose of defending against CA malfeasance -- from
the mechanisms we have available.
On Thu 2022-01-20 23:51:22 -0500, Ryan Sleevi wrote:
> There are good reasons that clients have not, and potentially
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
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 cavea
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: uta@ietf.org; t...@ietf.org
Subject: [TLS] OCSP in RFC7525bis
Hi,
RFC 7525 (the TLS BCP) has a section [1] with “weak” recommendations
> On 19 Jan 2022, at 9:57 am, Yaron Sheffer wrote:
>
> But this raises a larger question: many client-side implementations soft-fail
> if they don’t get an OCSP response within the handshake, i.e. they just
> ignore the problem. As far as we understand, this makes OCSP stapling
> completely in
On Wed, Jan 19, 2022 at 6:57 AM Yaron Sheffer wrote:
> Hi,
>
>
>
> RFC 7525 (the TLS BCP) has a section [1] with “weak” recommendations to
> use OCSP and OCSP stapling. We are changing these recommendations [2] in
> view of OCSP stapling in TLS 1.3 and the obsolescence of RFC 6961.
>
>
>
> But th
* We would be grateful for feedback based on implementation experience. In
particular if you have quantitative data on the use or quality of OCSP that’s
more recent than Chung18 [3], that would be very useful.
For what it’s worth, *our* customers want OCSP stapling. (It’s enabled by
default
Hi, RFC 7525 (the TLS BCP) has a section [1] with “weak” recommendations to use OCSP and OCSP stapling. We are changing these recommendations [2] in view of OCSP stapling in TLS 1.3 and the obsolescence of RFC 6961. But this raises a larger question: many client-side implementations soft-fail if th
13 matches
Mail list logo
