On 10/23/13 12:31 PM, Kathleen Wilson wrote:
On 10/22/13 1:19 PM, Eddy Nigg wrote:
I've been on the sidelines for most of this and other discussions here,
however I don't think this is correct at all - if the server doesn't
provide a correct stapled response, the browser must still be able to
find the OCSP response on its own. Additionally servers usually will use
the exact same information to find a valid OCSP response to include as a
browser would, and this response must be fairly frequently updated too.
Except if the server admin bothers to configure that manually which I
doubt over the longer term for most.
I'm not sure I understand your message. Are you saying that even if OCSP
stapling is used, the certs must have the OCSP URI in them, in case the
server's stapled response doesn't work, and the browser needs to
fallback to the OCSP URI in the cert?
There IS a significant risk if a certificate can't be revoked, this
isn't just about EV treatment. Stapling or not still requires to provide
a source to check for the certificates status independently, both for
the server AND in case stapling fails for this or the other reason
(outdated, wrong etc.).
Again, not sure if I'm understanding your message.
In the case of EV certs, Mozilla is still checking the CRL when the OCSP
URI is not provided. Though, I believe the plan is to stop checking CRL
in the future...
https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c34
"Instead of checking explicitly for an OCSP responder URI in the AIA
extension, let's simply remove the support for downloading CRLs from
Firefox's EV checking. That will have the effect of enforcing that all
certs in the chain have an OCSP AIA extension, except possibly for the
end-entity certificate if the server stapled the end-entity OCSP
response. I agree with the CA representatives that a missing OCSP AIA
URL isn't harmful when a stapled OCSP response is provided. So, I am OK
with allowing that exception, at least for now."
Are you saying that (instead of the above proposal) the revocation
checking should do the following?
1) Check for OCSP stapling response from server.
2) If cannot get a valid OCSP stapling response, then use OCSP URI in
AIA to try to get OCSP response.
3) If these attempts fail, then check CRL.
4) If both OCSP and CRL fail, then EV treatment will not be given.
Regards,
Kathleen
Unfortunately, OCSP stapling support has been delayed due to issues that
recently were found.
https://bugzilla.mozilla.org/show_bug.cgi?id=929617
There is discussion about this in CAB Forum Public list
(pub...@cabforum.org)
"We added support for OCSP stapling to Firefox 25 (beta) and we just
had to temporarily disable it right before the Firefox 25 release
because of interoperability issues. ..."
Kathleen
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
