>> Another 10 days have passed without any apparent sign of Mozilla's
>> willingness to address the case of the non-existence of an OCSP
>> responder for the Cybertrust SureServer EV CA.
Here is my opinion on this topic.
I don't believe there was an additional security risk caused by Verizon
not having the OCSP URI in their EV certificates, because Firefox will
not give EV treatment if there is no fresh revocation information via
CRL or OCSP.
Verizon had been asking for OCSP stapling before being required to
include the OCSP URI in the certs. Now that we have OCSP stapling
implemented in Firefox 25, I think we should allow Verizon some time to
move their customers from CRL to OCSP.
I don't think it actually helps anyone to remove Verizon's EV treatment
at this point in time. Many folks are of the opinion that EV treatment
should be removed for a few months as some sort of punishment, but I'm
not convinced that is actually necessary, because I think the negative
PR that Verizon got is sufficient at this time.
>
> And since CRL support was dropped in recent Firefox/Seamonkey
> releases there's
> no revocation checking mechanism for those certs at all.
>
That's not technically accurate for EV certificates. The user interface
to manually import CRLs was dropped, but CRLs are still being checked.
Currently for EV certs, if the OCSP URI is not present, then the CRL is
checked. EV treatment will not be given if current revocation status is
not successfully retrieved.
>
>> Their EV issuing CA has been non-compliant
>> for 2 years, 9 months, and 8 days by now. No wiggle room for any
>> discussion about effective dates etc., they undisputably failed to
>> implement a mandatory component of their revocation infrastructure
>> (and were certainly aware of this requirement in 2009, see
>>
https://groups.google.com/d/msg/mozilla.dev.security.policy/x_cuezl71OI/lt-ftQ0jmFoJ)
>
In that post Steven also made his plea for OCSP stapling: "We left that
meeting with a hope that ... we'd wait for TLS stapling of OCSP
responses to emerge before mandating OCSP for UI indication of an
Extended Validation process.
OCSP stapling has only just recently become available:
https://wiki.mozilla.org/CA:ImprovingRevocation#OCSP_Stapling
"Release: Firefox 25"
>
>> So in the case of Verizon, why does Mozilla not proceed with
>> removing their EV enablement?
As I mentioned previously, I don't believe the lack of OCSP URI in those
EV certificates was causing security risk to end users. Now that OCSP
stapling is available, I think we should give Verizon a little bit of
time to move their customers to OCSP.
Additionally, Verizon may not be the only CA with this issue, so I think
it is better that we solve it by enforcing it in code.
https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c34
2013-07-11 17:09:40 PDT
"So, now we have OCSP stapling enabled. ... there is now a requirement
that OCSP responders MUST NOT provide "good" responses for unknown
certificates in effect; this is a feature that CRLs do not have.
Therefore, I think we're more than justified in requiring that
revocation information be provided by OCSP for EV certificates."
Kathleen
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
