On 06.10.2013 20:52, Brian Smith wrote:
> I don't think there is much of a threat to our users from that
> certificate.
Not going to comment on this further. The point is BR compliance and
enforcement of Mozilla's CA Certificate Maintenance Policy, not
individual case-by-case risk management.
>> "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,
Fine. So in the case of Verizon, why does Mozilla not proceed with
removing their EV enablement? 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).
> and including the requirement that there must be an OCSP responder
> URI in the end-entity certificate.
That's not mandated by either the EV Guidelines or the BR. Stapling is
another viable option, so obviously the fix for bug 585122 needs to be
smarter than to just checking for a URI (or drop CRL support).
> 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.
Ok, so volunteers step forward, please... if Mozilla's reaction will
mostly consist of "applauding" such work and making statements like
"(for now) I am OK with the OCSP issues that were noted", it seems that
there's relatively little incentive for undertaking such work.
Kaspar
diff --git a/security/manager/ssl/src/nsIdentityChecking.cpp
b/security/manager/ssl/src/nsIdentityChecking.cpp
--- a/security/manager/ssl/src/nsIdentityChecking.cpp
+++ b/security/manager/ssl/src/nsIdentityChecking.cpp
@@ -135,27 +146,16 @@ static struct nsMyTrustedEVInfo myTruste
"FE:B8:C4:32:DC:F9:76:9A:CE:AE:3D:D8:90:8F:FD:28:86:65:64:7D",
"MGAxCzAJBgNVBAYTAkpQMSUwIwYDVQQKExxTRUNPTSBUcnVzdCBTeXN0ZW1zIENP"
"LixMVEQuMSowKAYDVQQLEyFTZWN1cml0eSBDb21tdW5pY2F0aW9uIEVWIFJvb3RD"
"QTE=",
"AA==",
nullptr
},
{
- // CN=Cybertrust Global Root,O=Cybertrust, Inc
- "1.3.6.1.4.1.6334.1.100.1",
- "Cybertrust EV OID",
- SEC_OID_UNKNOWN,
- "5F:43:E5:B1:BF:F8:78:8C:AC:1C:C7:CA:4A:9A:C6:22:2B:CC:34:C6",
- "MDsxGDAWBgNVBAoTD0N5YmVydHJ1c3QsIEluYzEfMB0GA1UEAxMWQ3liZXJ0cnVz"
- "dCBHbG9iYWwgUm9vdA==",
- "BAAAAAABD4WqLUg=",
- nullptr
- },
- {
// CN=SwissSign Gold CA - G2,O=SwissSign AG,C=CH
"2.16.756.1.89.1.2.1.1",
"SwissSign EV OID",
SEC_OID_UNKNOWN,
"D8:C5:38:8A:B7:30:1B:1B:6E:D4:7A:E6:45:25:3A:6F:9F:1A:27:61",
"MEUxCzAJBgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxHzAdBgNVBAMT"
"FlN3aXNzU2lnbiBHb2xkIENBIC0gRzI=",
"ALtAHEP1Xk+w",
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
