I utterly agree with Kaspar. There are CA's waiting to enable the EV check due to they did not support GET OCSP (could anyone explain what justifies this requirement?) since there are other CSP's "enjoying" its EV check without fulfilling the EV Reqs.
On Sun, Oct 6, 2013 at 8:52 PM, Brian Smith <[email protected]> wrote: > On Sun, Oct 6, 2013 at 7:36 AM, Kaspar Brand <[email protected]> wrote: > > My question to the browser vendors, in particular Mozilla, is still > > unanswered: > > > >> Doesn't that call for more a rigorous action from the browser vendors > >> (given that Verizon is apparently no longer a CABF member, so the > >> stick of cancelling their membership is already ineffective)? > > > As demonstrated by the cclearning.accenture.com case, Verizon does its > > own "risk assessment", decides to not follow the BR, Mozilla (Corp.) > > remains silent... and then everyone goes back to regular schedule? I > > don't think that's an appropriate way of dealing with this issue. > > Hi Kasper, > > I don't think there is much of a threat to our users from that > certificate. Also, please read Section 14.2.2 ("Enterprise RAs") of > the baseline requirements. Given that the EV requirements allow this > "Enterprise RA" practice and given that the *.cclearning.accenture.com > wildcard cert was at least "3rd level" it seems like a no harm / no > foul situation. > > Given that we have Safe Browsing, and given that browsers highlight > the eTLD+1 in the address bar to reduce the effectiveness of spoofing > using subdomains (e.g. paypal.services.com), and given that the > subject name of the cert is shown in the address bar for EV certs, > perhaps it isn't so bad to even change the EV requirements to allow > wildcard EV certs when the the eTLD+1 wouldn't result in confusion. > And, conversely, perhaps we should tighten the baseline requirements > to prevent the issuance of ANY kind of confusing wildcard certs. For > example, *.services.com or *.banking.com seems bad no matter whether > it is EV or not. Conversely, *.cclearning.accenture.com seems mostly > benign to me. > > > "CAs MUST support an OCSP capability for Subscriber Certificates that > > are issued after Dec 31, 2010." > > In the abstract, I support the removal of the EV indicator for certs > from CAs that don't meet our requirements for OCSP, including the > requirement that OCSP responders must return a signed "unknown" or > signed "revoked" response for unknown certificates, and including the > requirement that there must be an OCSP responder URI in the end-entity > certificate. I think it would be unreasonable for us to enforce the > requirement for "GET" at this time considering Firefox doesn't even > try "GET" yet, but that would eventually happen too. > > It would be great if a volunteer in this community could identify > which certificates in our EV program would be affected by such a > change, along with reproducable evidence of non-conformance. I think > that would educate us as to the extent of the change we would be > considering. > > Do you think we should remove the EV indicator for *all* certificates > that a CA issued, even if some/most of them included a link to a > correctly-functioning OCSP responder? Or, is it reasonable to just not > show the EV indicator when we are unable to obtain an OCSP response > for a particular certificate in question? We already have somebody > working on implementing the latter in bug 585122 [1]. If you that we > should remove the EV indicator from all of a CA's EV certificates if > *any* of them are missing OCSP functionality, then should the > privilege of getting the "EV indicator" also be contingent on non-EV > certs by that CA also meeting the requirement (which is now a baseline > requirement, not just EV)? > > I would like us to change our EV requirements so that a CA's entire > operation must be conformant to our policy (including the baseline > requirements, and including any externally-operated intermediates) > before we consider them to qualify for the EV privilege--i.e. we > should only give the EV-certificate-issuing privilege to our best > partners. > > Cheers, > Brian > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=585122 > > Cheers, > Brian > -- > Mozilla Networking/Crypto/Security (Necko/NSS/PSM) > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > -- [email protected] gplus.to/chemalogo +34 666 429 224 (Spain) @chemalogo <https://twitter.com/chemalogo> www.linkedin.com/in/chemalogo chemalogo _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
