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
