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. There is (weaker) consensus that OCSP is the preferred
solution, and no consensus at all about the technical details. For example,
clients failing hard is not in consensus - but neither is the opposite.
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 of)
revocation checking.
If you have not read the Pull Request, please note that it's a significant
change over RFC7525, e.g. 6961 is no longer recommended.
There was some back and forth about DNSSEC, short-lived certs, CAA and CT as
mitigating controls, but we don't see them as clearly in scope of the document.
Thanks,
Yaron
[1] https://github.com/yaronf/I-D/pull/279/files
---
From: Yaron Sheffer <yaronf.i...@gmail.com>
Date: Wednesday, January 19, 2022 at 16:57
To: "uta@ietf.org" <uta@ietf.org>, "t...@ietf.org" <t...@ietf.org>
Subject: OCSP in RFC7525bis
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 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
ineffective for what it’s trying to solve.
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 discussion of OCSP, saying that in its current form it’s not
adding value.
- Maintain the status quo, where many people implement OCSP on the server side,
but clients rarely benefit.
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.
Thanks,
Peter, Thomas and Yaron
PS: apologies for cross-posting.
[1] https://datatracker.ietf.org/doc/html/rfc7525#section-6.5
[2] https://github.com/yaronf/I-D/pull/279/files
[3] https://cbw.sh/static/pdf/chung-imc18.pdf
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
