> On 27 Jan 2022, at 4:45 pm, Yaron Sheffer wrote:
>
> So our plan moving forward is to essentially keep the new text on OCSP [1]
> and add a reference to RFC 7633 (the certificate must-staple extension). But
> only as a MAY. In addition, we will add a MUST requirement to perform (some
> kind
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 Mon 2022-01-24 13:06:13 +, John Mattsson wrote:
> I think another omission in RFC7525 that should be fixed in RFC7525 is
> a discussion on certificate life-times, which is often discussed
> together with revocation checking- Short-lived certificates is an
> improvement over long-lived certif
@ietf.org>>
Subject: RE: OCSP in RFC7525bis
Hi Yaron,
Where do you believe OCSP will be a good fit and why?
Ciao
Hannes
From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of
Yaron Sheffer
Sent: Wednesday, January 19, 2022 3:57 PM
To: u...@ietf.org<mailto:u...@ietf.org>; tls@iet
ect: RE: OCSP in RFC7525bis
Hi Yaron,
Where do you believe OCSP will be a good fit and why?
Ciao
Hannes
From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of
Yaron Sheffer
Sent: Wednesday, January 19, 2022 3:57 PM
To: u...@ietf.org<mailto:u...@ietf.org>; tls@ietf.org<mailto:tls@ie
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 clie
: OCSP in RFC7525bisHi Yaron, Where do you believe OCSP will be a good fit and why? CiaoHannes From: TLS On Behalf Of Yaron ShefferSent: Wednesday, January 19, 2022 3:57 PMTo: u...@ietf.org; tls@ietf.orgSubject: [TLS] OCSP in RFC7525bis Hi, RFC 7525 (the TLS BCP) has a section [1] with “weak
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 can
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
Hi,
> So for the new BCP, we have three options:
>
> 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.)
> Remove the whole di
Hi,
On Wed, 19 Jan 2022 16:57:07 +0200
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 complete
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
12 matches
Mail list logo
